Hi, I hope the week has gone well for everyone, despite all of the ongoing world events.
The issue surrounding launch control, at least on Linux, is a bit complex at this point. We are deeply involved with this issue so some background and clarifications for the benefit of everyone targeting SGX based solutions on the Linux platform, particularly groups that are interested in third party launch control.
At the current time, the driver that is proposed to become the mainstream Linux driver has no support for launch control. In fact, the ability to pass an initialization token (EINITTOKEN) to the ioctl system call that carries out enclave initialization has been specifically removed. Without the ability to pass a launch token into the kernel, a launch enclave has little or no value. In addition to the inability to pass a launch token into the kernel, the driver will refuse an attempt to initialize an enclave with the EINITTOKEN_KEY attribute. This denies the ability to even load a launch enclave on Linux.
The driver is instead configured to initialize any enclave that is handed to it. The driver computes the identity modulus signature of the enclave signing key and sets the launch control registers to that value. All of this effectively leaves the notion of 'launch control' to be the discretionary access controls that are applied to the SGX driver device node. This is problematic from a security perspective in that a full hardware chain of trust cannot be established, ie. any adversary that can defeat discretionary access controls can load and run enclave based code.
The potential security implications of this are well understood and are particularly problematic on SGX2 platforms that implement Enclave Dynamic Memory Management (EDMM). Since EDMM allows the dynamic loading and execution of code, an adversary can simply load a bootstrap enclave that can setup a confidential communications link to a command and control server and then download, over an encrypted channel, any adversarial code that is desired.
We've attempted to address this problem with a patch to the proposed driver that adds cryptographic initialization policy management to the driver, to the extent that such policy can be implemented on a platform with Flexible Launch Control.
Infrastructure is provided that allows the platform owner/administrator to designate identity modulus signatures of keys that control the following functionality:
- Keys that are allowed to sign enclaves (signing control).
- Keys that are allowed to sign launch enclaves.
- Keys that are allowed to sign enclaves that have the provisioning bit set.
After key signatures are registered, the lists can be 'locked' to prevent any further modifications to the policies. This is still not a hardware root of trust, since an adversary that gains the ability to modify kernel memory could still technically modify either the lock flag or the lists directly, but the barrier to doing so is arguably much higher then a simple breach of discretionary access controls.
Within the scope of this limitation, the policy management feature allows enclave based applications to be built and developed that are largely consistent with what can be developed on a locked launch control platform. If the platform administrator does not choose to implement any of these policies the driver will simply initialize any enclave presented to it.
The patch to implement this functionality against the most recent version of the driver can be downloaded from here if anyone is interested in following along at home.
We are proposing that this functionality be integrated into the mainstream driver, we will see what happens. The opposition to launch control is largely driven by the perceived politics of a locked launch control platform being against the ethos of open source. On a flexible launch control platform, with our patch, there is no technical rationale for continuing with this prohibition, and in fact, the behavior of the driver prohibits the owner of a platform from using the platform the way that they want to. Interestingly, the very thing that open source is opposed to.
Hopefully this provides useful background information on all of these issues. I'm not sure what Microsoft is doing on flexible launch control platforms but I would anticipate, given the potential security implications, that Microsoft is still retaining a cryptographically protected launch control model. Perhaps Jesus or others from the Intel SGX support team could provide some clarification on this issue.
We have found it interesting that some of the most vocal opposition against implementing cryptographic initialization policy has come from the Linux kernel developers employed by Intel. Hopefully our approach will be considered a reasoned alternative that implements the best of both worlds. It seems paradoxically inconsistent that all of this documentation would be available about third party launch control when the involved developers are specifically blocking the possibility of its implementation.
Hopefully all of this makes sense and is useful information.
Best wishes for a pleasant weekend.
Dr. Greg
