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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
