Michał Kowalczyk
3d31f2d18d
This is the next part of the great loader rework, with a lot of breaking changes: - Complete removal of the "trusted children" thing - now children processes can be spawned arbitrarily and from arbitrary mountpoint types, without any additional configuration needed. - There's a new, required option in the manifest: `libos.entrypoint` - it specifies the URI to the entry binary in the first process. There's no need anymore to name the manifest and the first binary identically. - On SGX, the main binary is not measured in MRENCLAVE anymore - only PAL, LibOS and the manifest are measured. This is enough to bind MRENCLAVE to a specific entrypoint user executable if wanted - it just has to be mounted as a trusted file. - All Graphene SGX enclaves have now exactly the same MRENCLAVE. This is a hash of a "Graphene stub", which can "fork" into one of two states in runtime: initial process or child. The initial process creates a new "Graphene namespace" with a clean state, it can also be attested remotely (contrary to child processes). The initial process can spawn children processes by spawning a Graphene stub and directing it to start in the child mode. It then attests it locally, and if successful, establishes an encrypted pipe, "connects" to its own namespace and treats as trusted (including sending protected files key). - Now, there's only one, central manifest describing the initial state of a Graphene instance which can be spawned from it (previously, each process required a separate manifest which could have different configuration - which wasn't actually supported and didn't make sense design-wise). One downside of central manifests is that all processes require the same enclave configuration (e.g. size), but that was already the case so far because of broken checkpointing code. Also, this is only a temporary problem, which will cease to exist after the introduction of EDMM. - `sgx.static_address` was renamed to `sgx.nonpie_binary` and now has to be inserted manually by users (`sgx_sign` tools doesn't know about the binaries run inside, which can be even provided or generated in runtime by the user's workload). - Caveat: the memory gap for non-PIE executables was removed because it requires adding a new option to the manifest to be cleanly implemented. This is left for some future loader rework PR.
Lighttpd Example
This directory contains an example for running lighttpd in Graphene, including the Makefile and a template for generating the manifest. We tested lighttpd on Ubuntu 16.04.
Building lighttpd source
For this example, we build lighttpd from source instead of using an existing binary. To build lighttpd on Ubuntu 16.04, please make sure that the following packages are installed:
sudo apt-get install -y build-essential apache2-utils
Linux
Run make (non-debug) or make DEBUG=1 (debug) in the directory.
SGX
Run make SGX=1 (non-debug) or make SGX=1 DEBUG=1 (debug) in the directory to prepare lighttpd to
run on SGX.
Running lighttpd natively, under Graphene, and under Graphene-SGX
Execute one of the following commands to start lighttpd either natively (non-Graphene), on Graphene or Graphene-SGX, respectively.
make start-native-server
make start-graphene-server
SGX=1 make start-graphene-server
Because these commands will start the lighttpd server in the foreground, you will need to open another console to run the client.
Once the server has started, you can test it with wget
wget http://127.0.0.1:8003/random/10K.1.html
You may also run the benchmark script using ab (Apachebench)
../common_tools/benchmark-http.sh 127.0.0.1:8003
Use Ctrl-C to terminate the server once you are finished testing lighttpd.
Clean up
There are two commands to clean up the directory:
make clean: Remove manifest, signature, and token files.make distclean: Remove the lighttpd source code and installation directory.