diff mbox series

[v37,02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits

Message ID 20200911124019.42178-3-jarkko.sakkinen@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series None | expand

Commit Message

Jarkko Sakkinen Sept. 11, 2020, 12:39 p.m. UTC 
From: Sean Christopherson <sean.j.christopherson@intel.com>

Add X86_FEATURE_SGX_LC, which informs whether or not the CPU supports SGX
Launch Control.

Add MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}, which when combined contain a
SHA256 hash of a 3072-bit RSA public key. SGX backed software packages, so
called enclaves, are always signed. All enclaves signed with the public key
are unconditionally allowed to initialize. [1]

Add FEAT_CTL_SGX_LC_ENABLED, which informs whether the aformentioned MSRs
are writable or not. If the bit is off, the public key MSRs are read-only
for the OS.

If the MSRs are read-only, the platform must provide a launch enclave (LE).
LE can create cryptographic tokens for other enclaves that they can pass
together with their signature to the ENCLS(EINIT) opcode, which is used
to initialize enclaves.

Linux is unlikely to support the locked configuration because it takes away
the control of the launch decisions from the kernel.

[1] Intel SDM: 38.1.4 Intel SGX Launch Control Configuration

Reviewed-by: Borislav Petkov <bp@alien8.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/include/asm/msr-index.h   | 7 +++++++
 2 files changed, 8 insertions(+)

Comments

Josh Poimboeuf Sept. 14, 2020, 3:18 p.m. UTC | #1 
Hi Jarko,

It looks like some of the patches weren't delivered to the lists.
Patches 0, 1, 8, 9, and 17 seem to be missing.

Lore agrees with me:

  https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/

On Fri, Sep 11, 2020 at 03:39:57PM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> Add X86_FEATURE_SGX_LC, which informs whether or not the CPU supports SGX
> Launch Control.
> 
> Add MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}, which when combined contain a
> SHA256 hash of a 3072-bit RSA public key. SGX backed software packages, so
> called enclaves, are always signed. All enclaves signed with the public key
> are unconditionally allowed to initialize. [1]
> 
> Add FEAT_CTL_SGX_LC_ENABLED, which informs whether the aformentioned MSRs
> are writable or not. If the bit is off, the public key MSRs are read-only
> for the OS.
> 
> If the MSRs are read-only, the platform must provide a launch enclave (LE).
> LE can create cryptographic tokens for other enclaves that they can pass
> together with their signature to the ENCLS(EINIT) opcode, which is used
> to initialize enclaves.
> 
> Linux is unlikely to support the locked configuration because it takes away
> the control of the launch decisions from the kernel.
> 
> [1] Intel SDM: 38.1.4 Intel SGX Launch Control Configuration
> 
> Reviewed-by: Borislav Petkov <bp@alien8.de>
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  arch/x86/include/asm/cpufeatures.h | 1 +
>  arch/x86/include/asm/msr-index.h   | 7 +++++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 159b635159c0..398e4f19c3d7 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -354,6 +354,7 @@
>  #define X86_FEATURE_CLDEMOTE		(16*32+25) /* CLDEMOTE instruction */
>  #define X86_FEATURE_MOVDIRI		(16*32+27) /* MOVDIRI instruction */
>  #define X86_FEATURE_MOVDIR64B		(16*32+28) /* MOVDIR64B instruction */
> +#define X86_FEATURE_SGX_LC		(16*32+30) /* Software Guard Extensions Launch Control */
>  
>  /* AMD-defined CPU features, CPUID level 0x80000007 (EBX), word 17 */
>  #define X86_FEATURE_OVERFLOW_RECOV	(17*32+ 0) /* MCA overflow recovery support */
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index c0b04f020162..e574b4bb5aad 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -602,6 +602,7 @@
>  #define FEAT_CTL_LOCKED				BIT(0)
>  #define FEAT_CTL_VMX_ENABLED_INSIDE_SMX		BIT(1)
>  #define FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX	BIT(2)
> +#define FEAT_CTL_SGX_LC_ENABLED			BIT(17)
>  #define FEAT_CTL_SGX_ENABLED			BIT(18)
>  #define FEAT_CTL_LMCE_ENABLED			BIT(20)
>  
> @@ -622,6 +623,12 @@
>  #define MSR_IA32_UCODE_WRITE		0x00000079
>  #define MSR_IA32_UCODE_REV		0x0000008b
>  
> +/* Intel SGX Launch Enclave Public Key Hash MSRs */
> +#define MSR_IA32_SGXLEPUBKEYHASH0	0x0000008C
> +#define MSR_IA32_SGXLEPUBKEYHASH1	0x0000008D
> +#define MSR_IA32_SGXLEPUBKEYHASH2	0x0000008E
> +#define MSR_IA32_SGXLEPUBKEYHASH3	0x0000008F
> +
>  #define MSR_IA32_SMM_MONITOR_CTL	0x0000009b
>  #define MSR_IA32_SMBASE			0x0000009e
>  
> -- 
> 2.25.1
>
Josh Poimboeuf Sept. 14, 2020, 3:38 p.m. UTC | #2 
On Mon, Sep 14, 2020 at 10:18:16AM -0500, Josh Poimboeuf wrote:
> Hi Jarko,
> 
> It looks like some of the patches weren't delivered to the lists.
> Patches 0, 1, 8, 9, and 17 seem to be missing.
> 
> Lore agrees with me:
> 
>   https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/

And my first email to you bounced, similar to an email I tried sending
to Kristen a few weeks ago.  Something weird going on with Intel mail
servers?
Sean Christopherson Sept. 14, 2020, 4:13 p.m. UTC | #3 
On Mon, Sep 14, 2020 at 10:38:12AM -0500, Josh Poimboeuf wrote:
> On Mon, Sep 14, 2020 at 10:18:16AM -0500, Josh Poimboeuf wrote:
> > Hi Jarko,
> > 
> > It looks like some of the patches weren't delivered to the lists.
> > Patches 0, 1, 8, 9, and 17 seem to be missing.
> > 
> > Lore agrees with me:
> > 
> >   https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/
> 
> And my first email to you bounced, similar to an email I tried sending
> to Kristen a few weeks ago.  Something weird going on with Intel mail
> servers?

Probably.  Our exchange servers got upgraded and many of the endpoints got
changed in the process.  It wouldn't surprise me in the least if there are
gremlins in the new setup.
Jarkko Sakkinen Sept. 15, 2020, 9:57 a.m. UTC | #4 
On Mon, Sep 14, 2020 at 10:38:26AM -0500, Josh Poimboeuf wrote:
> On Mon, Sep 14, 2020 at 10:18:16AM -0500, Josh Poimboeuf wrote:
> > Hi Jarko,
> > 
> > It looks like some of the patches weren't delivered to the lists.
> > Patches 0, 1, 8, 9, and 17 seem to be missing.
> > 
> > Lore agrees with me:
> > 
> >   https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/
> 
> And my first email to you bounced, similar to an email I tried sending
> to Kristen a few weeks ago.  Something weird going on with Intel mail
> servers?

Possible. I don't honestly know what is going on.

At least now all the patches are out:

https://lore.kernel.org/linux-sgx/

Not sure if a resend would make sense for the full patch set but maybe I
just do quick iteration and send v38 soon. And just in case use some alt
smtp server.

/Jarkko
Josh Poimboeuf Sept. 15, 2020, 1:27 p.m. UTC | #5 
On Tue, Sep 15, 2020 at 12:57:16PM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 14, 2020 at 10:38:26AM -0500, Josh Poimboeuf wrote:
> > On Mon, Sep 14, 2020 at 10:18:16AM -0500, Josh Poimboeuf wrote:
> > > Hi Jarko,
> > > 
> > > It looks like some of the patches weren't delivered to the lists.
> > > Patches 0, 1, 8, 9, and 17 seem to be missing.
> > > 
> > > Lore agrees with me:
> > > 
> > >   https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/
> > 
> > And my first email to you bounced, similar to an email I tried sending
> > to Kristen a few weeks ago.  Something weird going on with Intel mail
> > servers?
> 
> Possible. I don't honestly know what is going on.
> 
> At least now all the patches are out:
> 
> https://lore.kernel.org/linux-sgx/
> 
> Not sure if a resend would make sense for the full patch set but maybe I
> just do quick iteration and send v38 soon. And just in case use some alt
> smtp server.

I see the v37 missing patches now, but they're not threaded with the
original thread.  v38 has some missing patches as well.
Borislav Petkov Sept. 15, 2020, 1:39 p.m. UTC | #6 
On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote:
> I see the v37 missing patches now, but they're not threaded with the
> original thread.

Probably because he bounced only the ones you didn't get, separately.

> v38 has some missing patches as well.

And I got them twice. Can we please stop the spamming?

And yeah, use another mail service - all those companies switching the
o365 and mimecast, means time to move kernel development off of company
mail because company mail simply can't handle it.
Josh Poimboeuf Sept. 15, 2020, 2:02 p.m. UTC | #7 
On Tue, Sep 15, 2020 at 03:39:29PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote:
> > I see the v37 missing patches now, but they're not threaded with the
> > original thread.
> 
> Probably because he bounced only the ones you didn't get, separately.
> 
> > v38 has some missing patches as well.
> 
> And I got them twice. Can we please stop the spamming?
> 
> And yeah, use another mail service - all those companies switching the
> o365 and mimecast, means time to move kernel development off of company
> mail because company mail simply can't handle it.

If you getting them (twice?) and vger's not, it sounds like vger is
dropping them for some reason.
Borislav Petkov Sept. 15, 2020, 2:48 p.m. UTC | #8 
On Tue, Sep 15, 2020 at 09:02:50AM -0500, Josh Poimboeuf wrote:
> If you getting them (twice?) and vger's not, it sounds like vger is
> dropping them for some reason.

Yes, this has kinda been the case last and this week, for whatever
reason. From the two v38 submissions, I have only this in my LKML mbox
and it looks like someone is dropping mail...

109127 N C Sep 15           Jarkko Sakkinen ( : 35K|) [PATCH v38 00/24] Intel SGX foundations
109128 N C Sep 15           Jarkko Sakkinen ( : 14K|) ├─>[PATCH v38 04/24] x86/sgx: Add SGX microarchitectural data structures
109129 N C Sep 15           Jarkko Sakkinen ( : 10K|) ├─>[PATCH v38 05/24] x86/sgx: Add wrappers for ENCLS leaf functions
109130 N C Sep 15           Jarkko Sakkinen ( :4.5K|) ├─>[PATCH v38 07/24] x86/cpu/intel: Add nosgx kernel parameter
109131   C Sep 15           Jarkko Sakkinen ( :  60|) ├─>[PATCH v38 10/24] mm: Add vm_ops->mprotect()
109132 N C Sep 15           Jarkko Sakkinen ( : 14K|) ├─>[PATCH v38 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES
109133 N C Sep 15           Jarkko Sakkinen ( :9.1K|) ├─>[PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
109134 N C Sep 15           Jarkko Sakkinen ( : 15K|) ├─>[PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
109135 N C Sep 15           Jarkko Sakkinen ( :5.4K|) ├─>[PATCH v38 19/24] x86/fault: Add helper function to sanitize error code
109136 N C Sep 15           Jarkko Sakkinen ( :7.4K|) ├─>[PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling
109137 N C Sep 15           Jarkko Sakkinen ( : 34K|) ├─>[PATCH v38 22/24] selftests/x86: Add a selftest for SGX
109138 N C Sep 15           Jarkko Sakkinen ( : 12K|) ├─>[PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
109139 N C Sep 15           Jarkko Sakkinen ( :4.0K|) └─>[PATCH v38 24/24] x86/sgx: Update MAINTAINERS

109147 N C Sep 15           Jarkko Sakkinen ( :5.8K|) ┬─>[PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
109148 N C Sep 15           Jarkko Sakkinen ( :5.4K|) ├─>[PATCH v38 19/24] x86/fault: Add helper function to sanitize error code
109149 N C Sep 15           Jarkko Sakkinen ( :7.4K|) ├─>[PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling
109150 N C Sep 15           Jarkko Sakkinen ( : 15K|) ├─>[PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
109151 N C Sep 15           Jarkko Sakkinen ( : 12K|) └─>[PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
Jarkko Sakkinen Sept. 16, 2020, 3:57 p.m. UTC | #9 
On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote:
> On Tue, Sep 15, 2020 at 12:57:16PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 14, 2020 at 10:38:26AM -0500, Josh Poimboeuf wrote:
> > > On Mon, Sep 14, 2020 at 10:18:16AM -0500, Josh Poimboeuf wrote:
> > > > Hi Jarko,
> > > > 
> > > > It looks like some of the patches weren't delivered to the lists.
> > > > Patches 0, 1, 8, 9, and 17 seem to be missing.
> > > > 
> > > > Lore agrees with me:
> > > > 
> > > >   https://lore.kernel.org/linux-sgx/20200911124019.42178-1-jarkko.sakkinen@linux.intel.com/
> > > 
> > > And my first email to you bounced, similar to an email I tried sending
> > > to Kristen a few weeks ago.  Something weird going on with Intel mail
> > > servers?
> > 
> > Possible. I don't honestly know what is going on.
> > 
> > At least now all the patches are out:
> > 
> > https://lore.kernel.org/linux-sgx/
> > 
> > Not sure if a resend would make sense for the full patch set but maybe I
> > just do quick iteration and send v38 soon. And just in case use some alt
> > smtp server.
> 
> I see the v37 missing patches now, but they're not threaded with the
> original thread.  v38 has some missing patches as well.

Now, v38 is there as complete but it has a duplicate version (they have
exact same contents). Through the alternative mail server it just took
hours to get them to LKML so I did another git send-email :-(

Anyway, there is no difference between the patch sets marked as v38.

> 
> -- 
> Josh
> 

/Jarkko
Jarkko Sakkinen Sept. 16, 2020, 4:04 p.m. UTC | #10 
On Tue, Sep 15, 2020 at 03:39:29PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote:
> > I see the v37 missing patches now, but they're not threaded with the
> > original thread.
> 
> Probably because he bounced only the ones you didn't get, separately.
> 
> > v38 has some missing patches as well.
> 
> And I got them twice. Can we please stop the spamming?
> 
> And yeah, use another mail service - all those companies switching the
> o365 and mimecast, means time to move kernel development off of company
> mail because company mail simply can't handle it.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

The duplicate versions of v38 are equal. The "backup" server was just
really slow with vger. That's why I retried.

As can be seen here both v38's are also complete:

https://lore.kernel.org/linux-sgx/

I've tried for months to get kernel.org account but I have troubles
getting my PGP trusted. I really would like to move the whole thing
over there. And use that account for email.

Three maintainers have signed my key but when I do gpg --refresh, I
do not get any signatures for my key. The command uses keys.openpgp.org.
I have no idea if that is the correct key server or not. And I have no
idea how PGP servers mirror stuff with each other. And I have not found
anything on this from kernel documentation (e.g. PGP maintainer guide).

/Jarkko
Jarkko Sakkinen Sept. 16, 2020, 4:09 p.m. UTC | #11 
On Tue, Sep 15, 2020 at 09:02:50AM -0500, Josh Poimboeuf wrote:
> On Tue, Sep 15, 2020 at 03:39:29PM +0200, Borislav Petkov wrote:
> > On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote:
> > > I see the v37 missing patches now, but they're not threaded with the
> > > original thread.
> > 
> > Probably because he bounced only the ones you didn't get, separately.
> > 
> > > v38 has some missing patches as well.
> > 
> > And I got them twice. Can we please stop the spamming?
> > 
> > And yeah, use another mail service - all those companies switching the
> > o365 and mimecast, means time to move kernel development off of company
> > mail because company mail simply can't handle it.
> 
> If you getting them (twice?) and vger's not, it sounds like vger is
> dropping them for some reason.

It was my fault.

First time when I sent with mail.kapsi.fi I did not see anything for
like 20 minutes or so. I thought that things went wrong. So, I applied
git send-email another time for v38. Over hours both came to LKML as
can be seen from here:

https://lore.kernel.org/linux-sgx/

I'll try to sort out kernel.org account thing asap. Already sent my
key for the 2nd time to keys@linux.kernel.org albeit my PGP skills are
not good enough to check whether the signatures for my key are
somewhere.

/Jarkko
Borislav Petkov Sept. 16, 2020, 4:20 p.m. UTC | #12 
On Wed, Sep 16, 2020 at 07:04:19PM +0300, Jarkko Sakkinen wrote:
> The duplicate versions of v38 are equal. The "backup" server was just
> really slow with vger. That's why I retried.

Well, vger has been really slow for a while now...

> As can be seen here both v38's are also complete:
> 
> https://lore.kernel.org/linux-sgx/
> 
> I've tried for months to get kernel.org account but I have troubles
> getting my PGP trusted.

Have you tried this:

https://korg.docs.kernel.org/accounts.html

?

I believe you'll find enough people within Intel who are in the web of
trust.

> I really would like to move the whole thing over there. And use that
> account for email.

https://korg.docs.kernel.org/mail.html

You'd need mailbox hosting etc as k.org doesn't have that.

> Three maintainers have signed my key but when I do gpg --refresh, I
> do not get any signatures for my key. The command uses keys.openpgp.org.
> I have no idea if that is the correct key server or not. And I have no
> idea how PGP servers mirror stuff with each other. And I have not found
> anything on this from kernel documentation (e.g. PGP maintainer guide).

Yeah, see that accounts.html link I pasted above - "Exporting your
public key".

HTH.
diff mbox series

Patch

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 159b635159c0..398e4f19c3d7 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -354,6 +354,7 @@ 
 #define X86_FEATURE_CLDEMOTE		(16*32+25) /* CLDEMOTE instruction */
 #define X86_FEATURE_MOVDIRI		(16*32+27) /* MOVDIRI instruction */
 #define X86_FEATURE_MOVDIR64B		(16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_SGX_LC		(16*32+30) /* Software Guard Extensions Launch Control */
 
 /* AMD-defined CPU features, CPUID level 0x80000007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV	(17*32+ 0) /* MCA overflow recovery support */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c0b04f020162..e574b4bb5aad 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -602,6 +602,7 @@ 
 #define FEAT_CTL_LOCKED				BIT(0)
 #define FEAT_CTL_VMX_ENABLED_INSIDE_SMX		BIT(1)
 #define FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX	BIT(2)
+#define FEAT_CTL_SGX_LC_ENABLED			BIT(17)
 #define FEAT_CTL_SGX_ENABLED			BIT(18)
 #define FEAT_CTL_LMCE_ENABLED			BIT(20)
 
@@ -622,6 +623,12 @@ 
 #define MSR_IA32_UCODE_WRITE		0x00000079
 #define MSR_IA32_UCODE_REV		0x0000008b
 
+/* Intel SGX Launch Enclave Public Key Hash MSRs */
+#define MSR_IA32_SGXLEPUBKEYHASH0	0x0000008C
+#define MSR_IA32_SGXLEPUBKEYHASH1	0x0000008D
+#define MSR_IA32_SGXLEPUBKEYHASH2	0x0000008E
+#define MSR_IA32_SGXLEPUBKEYHASH3	0x0000008F
+
 #define MSR_IA32_SMM_MONITOR_CTL	0x0000009b
 #define MSR_IA32_SMBASE			0x0000009e