Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux