Add Java DaCapo benchmark sample + provide fixes

[prp]

This PR adds the Java DaCapo benchmark sample and attempts to fix #645.

A fundamental issue with SGX1 is that the in-enclave segfault handler does not receive the correct address of the memory access that caused the fault (instead before it received the address of the instruction causing the segfault). The Hotspot JVM uses guard pages that trigger segfaults to make threads reach safepoints for garbage collection. Since the faulting access isn't reported correctly, the JVM may be confused and segfault.

The PR also adds a new enclave_config option unsafe_host_signal, which controls if untrusted page faults are exposed to the enclave. It also adds a CI test that runs one of the DaCapo Java benchmarks.

In addition, the PR does some minor cleanup work:

• Move dumping of mount table to correct location (This was a previous merge error.)
• Output thread struct address in backtraces
• Fix dependency in Makefile for Java sample

[davidchisnall]

If the JVM is running in a configuration where it depends on SIGSEGV for functional correctness then it is insecure on current SGX. We should not be running benchmarks in that configuration because it's misleading. The GC should be configured to use explicit barriers in the JIT, not page protection.

[letmaik]

The benchmark test takes around 2 1/2 min. We may want to consider running this in the nightly build only.

[letmaik]

Why not just host-config.json?

[prp]

I like making them specific to the application, so from looking at the filename, you have a better understanding what's inside.

[letmaik]

I find that weird and I don't think we should advocate/recommend that. A folder should be the logical unit that groups things and inside that we have a standard layout. Don't you think?

[prp]

Hmm, I would say that there are two options:

1. We assume that the enclave/host configs should have well-known fixed filenames, i.e. enclave_config.json and host_config.json. This would be similar to the Dockerfile or Makefile convention. In that case though, the --encave-config and --host-config parameters should be optional and only needed if a user (for whatever reason) wants to override the filenames. This would be similar to how docker or make work -- otherwise we are forcing users to provide redundant options with each invocation.

2. We don't assume that there is a single approved filename and instead require users to be explicit (as it is now).

As you can tell, I'm in favour of (2), as I'm not a big fan of "magic" filenames that people must remember. That said, if people prefer (1), I'm also ok with that.

[prp]

If the JVM is running in a configuration where it depends on SIGSEGV for functional correctness then it is insecure on current SGX. We should not be running benchmarks in that configuration because it's misleading. The GC should be configured to use explicit barriers in the JIT, not page protection.

@davidchisnall I could not find a JVM configuration option to make the HotSpot JVM not use barriers based on page protection.