Messages in this thread | | | Subject | Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave | From | Jethro Beekman <> | Date | Wed, 20 Jun 2018 11:16:30 -0700 |
| |
On 2018-06-20 09:28, Nathaniel McCallum wrote: > As I understand it, the current policy models under discussion look like this: > > 1. SGX w/o FLC (not being merged) looks like this: > Intel CPU => (Intel signed) launch enclave => enclaves
I think you mean:
Intel CPU => kernel => (Intel signed) launch enclave => enclaves
> > 2. SGX w/ FLC, looks like this: > Intel CPU => kernel => launch enclave => enclaves > > 3. Andy is proposing this: > Intel CPU => kernel => enclaves > > This proposal is based on the fact that if the kernel can write to the > MSRs then a kernel compromise allows an attacker to run their own > launch enclave and therefore having an independent launch enclave adds > only complexity but not security. > > Is it possible to restrict the ability of the kernel to change the > MSRs? For example, could a UEFI module manage the MSRs? Could the > launch enclave live entirely within that UEFI module?
On 2017-03-17 09:15, Jethro Beekman wrote: > While collecting my thoughts about the issue I read through the > documentation again and it seems that it will not be possible for a > platform to lock in a non-Intel hash at all. From Section 39.1.4 of the > latest Intel SDM: > > > IA32_SGXLEPUBKEYHASH defaults to digest of Intel’s launch enclave > > signing key after reset. > > > > IA32_FEATURE_CONTROL bit 17 controls the permissions on the > > IA32_SGXLEPUBKEYHASH MSRs when CPUID.(EAX=12H, ECX=00H):EAX[0] = 1. > > If IA32_FEATURE_CONTROL is locked with bit 17 set, > > IA32_SGXLEPUBKEYHASH MSRs are reconfigurable (writeable). If either > > IA32_FEATURE_CONTROL is not locked or bit 17 is clear, the MSRs are > > read only. > > This last bit is also repeated in different words in Table 35-2 and > Section 42.2.2. The MSRs are *not writable* before the write-lock bit > itself is locked. Meaning the MSRs are either locked with Intel's key > hash, or not locked at all.
> > 4. I am suggesting this: > Intel CPU => UEFI module => enclaves > > Under this architecture, the kernel isn't involved in policy at all > and users get exactly the same freedoms they already have with Secure > Boot. Further, the launch enclave can be independently updated and > could be distributed in linux-firmware. The UEFI module can also be > shared across operating systems. If I want to have my own enclave > policy, then I can build the UEFI module myself, with my > modifications, and I can disable Secure Boot. Alternatively, > distributions that want to set their own policies can build their own > UEFI module and sign it with their vendor key.
Jethro Beekman | Fortanix
[unhandled content-type:application/pkcs7-signature] | |