| Message ID | 20200911124019.42178-3-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | None | expand |
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 >
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?
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.
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
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.
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.
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.
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
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
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
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
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 --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