linux-kernel - Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e3f8e5b9-aa1e-20da-37ac-3c3caafa66bc@fortanix.com>
Date:   Wed, 20 Jun 2018 11:16:30 -0700
From:   Jethro Beekman <jethro@...tanix.com>
To:     Nathaniel McCallum <npmccallum@...hat.com>, luto@...nel.org
Cc:     Neil Horman <nhorman@...hat.com>, jarkko.sakkinen@...ux.intel.com,
        x86@...nel.org, platform-driver-x86@...r.kernel.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        intel-sgx-kernel-dev@...ts.01.org, hpa@...or.com,
        dvhart@...radead.org, tglx@...utronix.de, andy@...radead.org,
        Peter Jones <pjones@...hat.com>
Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel
 launch enclave

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


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3994 bytes)