Add support for RELEASE builds of SGX-LKL

[prp]

Build types for SGX-LKL

We want to support the following three mutually-exclusive build types for SGX-LKL:

1. make DEBUG=true # DEBUG build

This creates a debug build of SGX-LKL with full debug and tracing functionality, debug symbols and -O0.

This version should be used for development of SGX-LKL. It is not secure because it permits execution without attestation and secrets (e.g., root encryption keys) can be passed directly to the launcher via environment variables.

2. make # NON-RELEASE build

This builds a version of SGX-LKL with some (low-overhead) debug and tracing functionality, no debug symbols and -O3. This is the default build when no make target is specified.

This version should be used for performance benchmarking and testing. It is not secure because it permits execution without attestation and secrets (e.g., root encryption keys) can be passed directly to the launcher via environment variables.

3. make RELEASE=true # RELEASE build

This builds a release version of SGX-LKL without debug functionality, no debug symbols and -O3.

This version should be used for production deployments because it is the only version that is secure. It excludes any code from the enclave that compromises security, i.e., it:

• removes support for execution of SGX-LKL in software mode;
• requires a valid app_config to be specified, as all app config environment variables are ignored;
• only permits execution of a non-debug OE hardware enclave;
• enforces attestation, so it becomes impossible to run an enclave application locally (without access to an attestation and key release service) for testing;
• deactivates output/input from/to the LKL console, which would otherwise constitute data leakage from the enclave.

Packaging of build types

The different builds of SGX-LKL could be installed in difference directory prefixes on the file system, e.g.:

• /opt/sgx-lkl-debug/
• /opt/sgx-lkl-non-release/
• /opt/sgx-lkl-release/

We could have a symlink sgx-lkl that points to one of them (e.g. the RELEASE build to have security by default?). When launching sgx-lkl-run-oe, it outputs clearly which version it is.

Dependencies

• The implementation of a RELEASE build depends on attestation support.
• The changes to the build system should probably happen after the overall build system has been updated.

cc: @letmaik @wintersteiger @davidchisnall @paulcallen @jxyang

[letmaik]

I don't think it's a good idea to have different launcher names. This will complicate any kind of automation. Why not simply use a different installation prefix and keep everything inside the same?

[prp]

I've updated the original issue per our discussion today. Please add other thoughts/suggestions, thanks.

[letmaik]

Symlinking /opt/sgx-lkl to /opt/sgx-lkl-release will be problematic for the case when the former prefix would be mounted into a container. I'm pretty sure you wouldn't be able to run it without not also mounting the real folder. I think in general we want to have a /opt/sgx-lkl, but do we care whether /opt/sgx-lkl-release exists? If not, we could make /opt/sgx-lkl the release variant and don't have symlinks at all.

[jxyang]

I am not clear about this statement:

enforces attestation, so it becomes impossible to run an enclave application locally for testing;

By locally, you mean running the application without a peer which provide critical info such as keys? Maybe instead of saying this is impossible for release build, we should state how this is circumvented in non-release/debug build.

[prp]

I am not clear about this statement:

enforces attestation, so it becomes impossible to run an enclave application locally for testing;

By locally, you mean running the application without a peer which provide critical info such as keys? Maybe instead of saying this is impossible for release build, we should state how this is circumvented in non-release/debug build.

That’s right. I’ve updated the original issue to reflect this.

[prp]

Symlinking /opt/sgx-lkl to /opt/sgx-lkl-release will be problematic for the case when the former prefix would be mounted into a container. I'm pretty sure you wouldn't be able to run it without not also mounting the real folder. I think in general we want to have a /opt/sgx-lkl, but do we care whether /opt/sgx-lkl-release exists? If not, we could make /opt/sgx-lkl the release variant and don't have symlinks at all.

An alternative idea would be to have:

• /opt/sgx-lkl/release/
• /opt/sgx-lkl/non-release/
• /opt/sgx-lkl/debug/

and also a default symlink?

[letmaik]

Well, if you have /opt/sgx-lkl/debug/, how can you have a symlink at /opt/sgx-lkl? Or did you mean to use dashes? If so, then it's fine of course.

[prp]

Well, if you have /opt/sgx-lkl/debug/, how can you have a symlink at /opt/sgx-lkl? Or did you mean to use dashes? If so, then it's fine of course.

Right, the symlink would have to be called default or some such.

[letmaik]

Who would use the symlink?

[prp]

Who would use the symlink?

It’s a default for people who are confused by the build types? :-) I guess we don’t need the symlink.

[letmaik]

Regarding the properties of a release build, I don't think the following are required explicitly:

• removes support for execution of SGX-LKL in software mode;
• only permits execution of a non-debug OE hardware enclave;
• enforces attestation, so it becomes impossible to run an enclave application locally (without access to an attestation and key release service) for testing;

All of these would already be enforced by the policies of a key release service. For release deployments the policy would only allow non-debug hardware enclaves. There is no additional security in having the three points above implemented.

[prp]

@letmaik to me, a RELEASE build is not about what attestation enforces but rather about removing unnecessary code and functionality from the enclave, and thus getting a smaller TCB. By removing this functionality, we reduce the attack surface.

[SeanTAllen]

This is p1 for the design doc at which point this should be reprioritized.