From: Jethro Beekman <jethro@fortanix.com>
To: Nathaniel McCallum <npmccallum@redhat.com>, luto@kernel.org
Cc: Neil Horman <nhorman@redhat.com>,
jarkko.sakkinen@linux.intel.com, x86@kernel.org,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
intel-sgx-kernel-dev@lists.01.org, hpa@zytor.com,
dvhart@infradead.org, tglx@linutronix.de, andy@infradead.org,
Peter Jones <pjones@redhat.com>
Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
Date: Wed, 20 Jun 2018 11:16:30 -0700 [thread overview]
Message-ID: <e3f8e5b9-aa1e-20da-37ac-3c3caafa66bc@fortanix.com> (raw)
In-Reply-To: <CAOASepN9t3jF4ajfKLG_odTZddOvXjY_DqLQhRPWhJ-imtjkgg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3994 bytes --]
next prev parent reply other threads:[~2018-06-20 18:16 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-08 17:09 [PATCH v11 00/13] Intel SGX1 support Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 01/13] compiler.h, kasan: add __SANITIZE_ADDRESS__ check for __no_kasan_or_inline Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 02/13] x86, sgx: updated MAINTAINERS Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 03/13] x86, sgx: add SGX definitions to cpufeature Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 04/13] x86, sgx: add SGX definitions to msr-index.h Jarkko Sakkinen
2018-06-08 17:25 ` Dave Hansen
2018-06-19 13:18 ` Jarkko Sakkinen
2018-06-19 14:01 ` Dave Hansen
2018-06-21 17:22 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 05/13] x86, cpufeatures: add Intel-defined SGX leaf CPUID_12_EAX Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 06/13] crypto: aesni: add minimal build option for SGX LE Jarkko Sakkinen
2018-06-08 17:27 ` Dave Hansen
2018-06-11 15:24 ` Sean Christopherson
2018-06-08 17:09 ` [PATCH v11 07/13] x86, sgx: detect Intel SGX Jarkko Sakkinen
2018-06-08 17:36 ` Dave Hansen
2018-06-18 21:36 ` [intel-sgx-kernel-dev] " Andy Lutomirski
2018-06-25 7:39 ` Jarkko Sakkinen
2018-06-19 13:33 ` Jarkko Sakkinen
2018-06-11 11:35 ` Neil Horman
2018-06-19 13:34 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 08/13] x86, sgx: added ENCLS wrappers Jarkko Sakkinen
2018-06-08 17:43 ` Dave Hansen
2018-06-19 13:25 ` Jarkko Sakkinen
2018-06-20 13:12 ` Sean Christopherson
2018-06-25 9:16 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 09/13] x86, sgx: basic routines for enclave page cache Jarkko Sakkinen
2018-06-08 18:21 ` Jethro Beekman
2018-06-18 21:33 ` [intel-sgx-kernel-dev] " Andy Lutomirski
2018-06-25 7:36 ` Jarkko Sakkinen
2018-06-19 14:08 ` Jarkko Sakkinen
2018-06-19 15:44 ` Jethro Beekman
2018-06-08 18:24 ` Dave Hansen
2018-06-19 14:57 ` Jarkko Sakkinen
2018-06-19 15:19 ` Neil Horman
2018-06-19 15:32 ` Dave Hansen
2018-06-25 9:01 ` Jarkko Sakkinen
2018-06-19 15:59 ` Sean Christopherson
2018-06-25 9:14 ` Jarkko Sakkinen
2018-06-10 5:32 ` [intel-sgx-kernel-dev] " Andy Lutomirski
2018-06-11 15:12 ` Sean Christopherson
2018-06-20 13:21 ` Sean Christopherson
2018-06-25 9:21 ` Jarkko Sakkinen
2018-06-25 16:14 ` Neil Horman
2018-06-20 15:26 ` Sean Christopherson
2018-06-25 9:21 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 10/13] intel_sgx: driver for Intel Software Guard Extensions Jarkko Sakkinen
2018-06-08 19:35 ` Dave Hansen
2018-06-19 13:29 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 11/13] intel_sgx: ptrace() support Jarkko Sakkinen
2018-06-08 18:34 ` Dave Hansen
2018-06-11 15:02 ` Sean Christopherson
2018-06-19 13:38 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 12/13] intel_sgx: driver documentation Jarkko Sakkinen
2018-06-08 18:32 ` Jethro Beekman
2018-06-19 13:30 ` Jarkko Sakkinen
2018-06-08 21:41 ` Randy Dunlap
2018-06-19 13:31 ` Jarkko Sakkinen
2018-06-08 17:09 ` [PATCH v11 13/13] intel_sgx: in-kernel launch enclave Jarkko Sakkinen
2018-06-08 18:50 ` [intel-sgx-kernel-dev] " Andy Lutomirski
2018-06-19 15:05 ` Jarkko Sakkinen
2018-06-10 5:39 ` Andy Lutomirski
2018-06-11 5:17 ` Andy Lutomirski
2018-06-11 11:52 ` Neil Horman
2018-06-12 4:55 ` Andy Lutomirski
2018-06-12 17:45 ` Neil Horman
2018-06-18 21:58 ` Andy Lutomirski
2018-06-19 13:17 ` Neil Horman
2018-06-20 16:28 ` Nathaniel McCallum
2018-06-20 18:16 ` Jethro Beekman [this message]
2018-06-20 18:39 ` Jethro Beekman
2018-06-20 21:01 ` Sean Christopherson
2018-06-21 12:32 ` Nathaniel McCallum
2018-06-21 15:29 ` Neil Horman
2018-06-21 19:11 ` Nathaniel McCallum
2018-06-21 21:20 ` Sean Christopherson
2018-06-25 21:00 ` Nathaniel McCallum
2018-06-25 22:35 ` Sean Christopherson
2018-06-21 22:48 ` Andy Lutomirski
2018-06-25 21:06 ` Nathaniel McCallum
2018-06-25 23:40 ` Andy Lutomirski
2018-06-25 9:41 ` Jarkko Sakkinen
2018-06-25 15:45 ` Andy Lutomirski
2018-06-25 21:28 ` Nathaniel McCallum
2018-06-26 8:43 ` Jarkko Sakkinen
2018-06-26 15:01 ` Nathaniel McCallum
2018-06-27 15:31 ` Jarkko Sakkinen
2018-06-21 12:12 ` Nathaniel McCallum
2018-06-25 9:27 ` Jarkko Sakkinen
2018-06-25 21:26 ` Nathaniel McCallum
2018-06-20 7:23 ` Jarkko Sakkinen
2018-06-12 10:50 ` [PATCH v11 00/13] Intel SGX1 support Pavel Machek
2018-06-19 14:59 ` Jarkko Sakkinen
2018-06-19 20:04 ` Pavel Machek
2018-06-19 20:23 ` Peter Zijlstra
2018-06-19 21:48 ` Josh Triplett
2018-12-09 20:06 ` Pavel Machek
2018-12-10 7:47 ` Josh Triplett
2018-12-10 8:27 ` Pavel Machek
2018-12-10 23:12 ` Josh Triplett
2018-12-11 18:10 ` Dave Hansen
2018-12-11 18:31 ` Sean Christopherson
2018-06-19 20:36 ` Peter Zijlstra
2018-06-21 12:55 ` Ingo Molnar
2018-06-25 9:44 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e3f8e5b9-aa1e-20da-37ac-3c3caafa66bc@fortanix.com \
--to=jethro@fortanix.com \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=intel-sgx-kernel-dev@lists.01.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=pjones@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).