Add Java DaCapo benchmark sample provide fixes #646
Conversation
prp
changed the title
prp
changed the title
There was a problem hiding this comment.
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.
Otherwise a bunch of tests get broken.
prp
changed the title
| @@ -0,0 1,9 @@ | |||
| { | |||
There was a problem hiding this comment.
Why not just host-config.json?
There was a problem hiding this comment.
I like making them specific to the application, so from looking at the filename, you have a better understanding what's inside.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Hmm, I would say that there are two options:
-
We assume that the enclave/host configs should have well-known fixed filenames, i.e.
enclave_config.jsonandhost_config.json. This would be similar to theDockerfileorMakefileconvention. In that case though, the--encave-configand--host-configparameters should be optional and only needed if a user (for whatever reason) wants to override the filenames. This would be similar to howdockerormakework -- otherwise we are forcing users to provide redundant options with each invocation. -
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.
@davidchisnall I could not find a JVM configuration option to make the HotSpot JVM not use barriers based on page protection. |
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: