Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, 2018-06-26 at 11:01 -0400, Nathaniel McCallum wrote: > On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen > wrote: > > > > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > > > I'm personally rather strongly in favor of the vastly simpler model in > > > which we first merge SGX without LE support at all. Instead we use > > > the approach where we just twiddle the MSRs to launch normal enclaves > > > without an init token at all, which is probably considerably faster > > > and will remove several thousand lines of code. If and when a bona > > > fide use case for LE support shows up, we can work out the details and > > > merge it. > > > > Andy, I was going to propose exactly the same :-) > > > > We can upstream SGX that supports only unlocked MSRs and that does > > not preventing to upstream support for locked MSRs later. Even if > > we had a consensus for locked MSRs, making two milestones for the > > mainline would make perfect sense. > > > > I came into this conclusion last night because all the other review > > comments not concerning the launch control are easily sorted out. > > +1. Let's do this and get it merged without launch enclave support > lockdown now. We can revisit this once we have hands on experience > with the technology. I'm proceeding with this ATM. I'm going to send v12 next week. I'll do my best to address all of the review comments but expect to miss some of them. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, 2018-06-26 at 11:01 -0400, Nathaniel McCallum wrote: > On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen > wrote: > > > > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > > > I'm personally rather strongly in favor of the vastly simpler model in > > > which we first merge SGX without LE support at all. Instead we use > > > the approach where we just twiddle the MSRs to launch normal enclaves > > > without an init token at all, which is probably considerably faster > > > and will remove several thousand lines of code. If and when a bona > > > fide use case for LE support shows up, we can work out the details and > > > merge it. > > > > Andy, I was going to propose exactly the same :-) > > > > We can upstream SGX that supports only unlocked MSRs and that does > > not preventing to upstream support for locked MSRs later. Even if > > we had a consensus for locked MSRs, making two milestones for the > > mainline would make perfect sense. > > > > I came into this conclusion last night because all the other review > > comments not concerning the launch control are easily sorted out. > > +1. Let's do this and get it merged without launch enclave support > lockdown now. We can revisit this once we have hands on experience > with the technology. I'm proceeding with this ATM. I'm going to send v12 next week. I'll do my best to address all of the review comments but expect to miss some of them. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen wrote: > > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > > I'm personally rather strongly in favor of the vastly simpler model in > > which we first merge SGX without LE support at all. Instead we use > > the approach where we just twiddle the MSRs to launch normal enclaves > > without an init token at all, which is probably considerably faster > > and will remove several thousand lines of code. If and when a bona > > fide use case for LE support shows up, we can work out the details and > > merge it. > > Andy, I was going to propose exactly the same :-) > > We can upstream SGX that supports only unlocked MSRs and that does > not preventing to upstream support for locked MSRs later. Even if > we had a consensus for locked MSRs, making two milestones for the > mainline would make perfect sense. > > I came into this conclusion last night because all the other review > comments not concerning the launch control are easily sorted out. +1. Let's do this and get it merged without launch enclave support lockdown now. We can revisit this once we have hands on experience with the technology.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen wrote: > > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > > I'm personally rather strongly in favor of the vastly simpler model in > > which we first merge SGX without LE support at all. Instead we use > > the approach where we just twiddle the MSRs to launch normal enclaves > > without an init token at all, which is probably considerably faster > > and will remove several thousand lines of code. If and when a bona > > fide use case for LE support shows up, we can work out the details and > > merge it. > > Andy, I was going to propose exactly the same :-) > > We can upstream SGX that supports only unlocked MSRs and that does > not preventing to upstream support for locked MSRs later. Even if > we had a consensus for locked MSRs, making two milestones for the > mainline would make perfect sense. > > I came into this conclusion last night because all the other review > comments not concerning the launch control are easily sorted out. +1. Let's do this and get it merged without launch enclave support lockdown now. We can revisit this once we have hands on experience with the technology.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > I'm personally rather strongly in favor of the vastly simpler model in > which we first merge SGX without LE support at all. Instead we use > the approach where we just twiddle the MSRs to launch normal enclaves > without an init token at all, which is probably considerably faster > and will remove several thousand lines of code. If and when a bona > fide use case for LE support shows up, we can work out the details and > merge it. Andy, I was going to propose exactly the same :-) We can upstream SGX that supports only unlocked MSRs and that does not preventing to upstream support for locked MSRs later. Even if we had a consensus for locked MSRs, making two milestones for the mainline would make perfect sense. I came into this conclusion last night because all the other review comments not concerning the launch control are easily sorted out. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote: > I'm personally rather strongly in favor of the vastly simpler model in > which we first merge SGX without LE support at all. Instead we use > the approach where we just twiddle the MSRs to launch normal enclaves > without an init token at all, which is probably considerably faster > and will remove several thousand lines of code. If and when a bona > fide use case for LE support shows up, we can work out the details and > merge it. Andy, I was going to propose exactly the same :-) We can upstream SGX that supports only unlocked MSRs and that does not preventing to upstream support for locked MSRs later. Even if we had a consensus for locked MSRs, making two milestones for the mainline would make perfect sense. I came into this conclusion last night because all the other review comments not concerning the launch control are easily sorted out. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 2:06 PM Nathaniel McCallum wrote: > > On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote: > > > > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum > > wrote: > > > > > > If this is acceptable for everyone, my hope is the following: > > > > > > 1. Intel would split the existing code into one of the following > > > schemas (I don't care which): > > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > > launch enclave > > > B. two parts: UEFI module (including launch enclave) and FLC-only > > > kernel driver > > > > > > 2. Intel would release a reproducible build of the GPL UEFI module > > > sources signed with a SecureBoot trusted key and provide an > > > acceptable[0] binary redistribution license. > > > > > > 3. The kernel community would agree to merge the kernel driver given > > > the above criteria (and, obviously, acceptable kernel code). > > > > > > The question of how to distribute the UEFI module and possible launch > > > enclave remains open. I see two options: independent distribution and > > > bundling it in linux-firmware. The former may be a better > > > technological fit since the UEFI module will likely need to be run > > > before the kernel (and the boot loader; and shim). However, the latter > > > has the benefit of already being a well-known entity to our downstream > > > distributors. I could go either way on this. > > > > This is a lot of complication and effort for a gain that is not > > entirely clear. > > Root kits and evil maid attacks are two worth considering. > I think that SGX malware is a real issue. I'm less convinced that SGX root kits and SGX evil maid attacks are particularly interesting, except insofar as SGX can be used to make a root kit's behavior harder to reverse engineer. Can you explain exactly what type of attack you have in mind and exactly how all this complexity helps? (Keep in mind that SGX, by itself, cannot actually obfuscate malware. SGX plus a command-and-control system that uses remote attestation *can* obfuscate malware, but Intel has tight [0], online controls to protect against *that*, and they have nothing to do with launch control [1].) > > I really really really do *not* want to see Intel or > > anyone else start enforcing policy on which programs can and cannot > > run using this mechanism. > > We already do this. It is called SecureBoot. And we have a mechanism for letting people run whatever OS they want on a SecureBoot system, and if you can get your favorite Linux to boot on a Secure Boot machine, it's fully functional. SGX, not so much. > > > (This is exactly why non-FLC systems aren't > > about to be supported upstream.) So my preference is to not merge > > anything that supports this type of use case unless there is > > compelling evidence that it is (a) genuinely useful, (b) will be used > > to improve security and (c) won't be abused for, say, revenue > > purposes. > > I think there are benefits for (a) and (b). I agree with you about > (c). But, again, we already have SecureBoot. And Secure Boot is great (aside from being overcomplicated, using SMM in ridiculous ways, and having some misguided OEMs providing buggy implementations). And Secure Boot, applied correctly, is decent protection against root kits independently of SGX. [0] Well, maybe they're tight. I don't know whether Intel pays adequate attention. Also, IIRC, you need an NDA to even learn the rules about Intel's attestation service. [1] I'd need to reread the SDM, but it's possible that a buggy signed-by-Intel launch enclave would break attestation. But a not-signed-by-Intel enclave can't have any particular effect on attestation, because the *attestation* root of trust involves Intel knowing the provisioning keys of all the genuine SGX CPUs in the world, and Intel is the only party with that information, so a third-party provisioning enclave signed by a third party can't actually root its trust anywhere. This situation is somewhat analogous to how TPM-based DRM used to be impossible but is not sort-of-possible even though TPMs have never had any equivalent of launch control.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 2:06 PM Nathaniel McCallum wrote: > > On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote: > > > > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum > > wrote: > > > > > > If this is acceptable for everyone, my hope is the following: > > > > > > 1. Intel would split the existing code into one of the following > > > schemas (I don't care which): > > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > > launch enclave > > > B. two parts: UEFI module (including launch enclave) and FLC-only > > > kernel driver > > > > > > 2. Intel would release a reproducible build of the GPL UEFI module > > > sources signed with a SecureBoot trusted key and provide an > > > acceptable[0] binary redistribution license. > > > > > > 3. The kernel community would agree to merge the kernel driver given > > > the above criteria (and, obviously, acceptable kernel code). > > > > > > The question of how to distribute the UEFI module and possible launch > > > enclave remains open. I see two options: independent distribution and > > > bundling it in linux-firmware. The former may be a better > > > technological fit since the UEFI module will likely need to be run > > > before the kernel (and the boot loader; and shim). However, the latter > > > has the benefit of already being a well-known entity to our downstream > > > distributors. I could go either way on this. > > > > This is a lot of complication and effort for a gain that is not > > entirely clear. > > Root kits and evil maid attacks are two worth considering. > I think that SGX malware is a real issue. I'm less convinced that SGX root kits and SGX evil maid attacks are particularly interesting, except insofar as SGX can be used to make a root kit's behavior harder to reverse engineer. Can you explain exactly what type of attack you have in mind and exactly how all this complexity helps? (Keep in mind that SGX, by itself, cannot actually obfuscate malware. SGX plus a command-and-control system that uses remote attestation *can* obfuscate malware, but Intel has tight [0], online controls to protect against *that*, and they have nothing to do with launch control [1].) > > I really really really do *not* want to see Intel or > > anyone else start enforcing policy on which programs can and cannot > > run using this mechanism. > > We already do this. It is called SecureBoot. And we have a mechanism for letting people run whatever OS they want on a SecureBoot system, and if you can get your favorite Linux to boot on a Secure Boot machine, it's fully functional. SGX, not so much. > > > (This is exactly why non-FLC systems aren't > > about to be supported upstream.) So my preference is to not merge > > anything that supports this type of use case unless there is > > compelling evidence that it is (a) genuinely useful, (b) will be used > > to improve security and (c) won't be abused for, say, revenue > > purposes. > > I think there are benefits for (a) and (b). I agree with you about > (c). But, again, we already have SecureBoot. And Secure Boot is great (aside from being overcomplicated, using SMM in ridiculous ways, and having some misguided OEMs providing buggy implementations). And Secure Boot, applied correctly, is decent protection against root kits independently of SGX. [0] Well, maybe they're tight. I don't know whether Intel pays adequate attention. Also, IIRC, you need an NDA to even learn the rules about Intel's attestation service. [1] I'd need to reread the SDM, but it's possible that a buggy signed-by-Intel launch enclave would break attestation. But a not-signed-by-Intel enclave can't have any particular effect on attestation, because the *attestation* root of trust involves Intel knowing the provisioning keys of all the genuine SGX CPUs in the world, and Intel is the only party with that information, so a third-party provisioning enclave signed by a third party can't actually root its trust anywhere. This situation is somewhat analogous to how TPM-based DRM used to be impossible but is not sort-of-possible even though TPMs have never had any equivalent of launch control.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 05:00:05PM -0400, Nathaniel McCallum wrote: > On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson > wrote: > > > > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > > > If this is acceptable for everyone, my hope is the following: > > > > > > 1. Intel would split the existing code into one of the following > > > schemas (I don't care which): > > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > > launch enclave > > > B. two parts: UEFI module (including launch enclave) and FLC-only > > > kernel driver > > > > To make sure I understand correctly... > > > > The UEFI module would lock the LE MSRs with a public key hardcoded > > into both the UEFI module and the kernel at build time? > > > > And for the kernel, it would only load its SGX driver if FLC is > > supported and the MSRs are locked to the expected key? > > > > IIUC, this approach will cause problems for virtualization. Running > > VMs with different LE keys would require the bare metal firmware to > > configure the LE MSRs to be unlocked, which would effectively make > > using SGX in the host OS mutually exlusive with exposing SGX to KVM > > guests. Theoretically it would be possible for KVM to emulate the > > guest's LE and use the host's LE to generate EINIT tokens, but > > emulating an enclave would likely require a massive amount of code > > and/or complexity. > > How is this different from any other scenario where you lock the LE > MSRs? Unless Intel provides hardware support between the LE MSRs and > the VMX instructions, I don't see any way around this besides letting > any launch enclave run. It's not. All prior discussions have effectively required unlocked MSRs, so that's my baseline. > > > 2. Intel would release a reproducible build of the GPL UEFI module > > > sources signed with a SecureBoot trusted key and provide an > > > acceptable[0] binary redistribution license. > > > > > > 3. The kernel community would agree to merge the kernel driver given > > > the above criteria (and, obviously, acceptable kernel code). > > > > > > The question of how to distribute the UEFI module and possible launch > > > enclave remains open. I see two options: independent distribution and > > > bundling it in linux-firmware. The former may be a better > > > technological fit since the UEFI module will likely need to be run > > > before the kernel (and the boot loader; and shim). However, the latter > > > has the benefit of already being a well-known entity to our downstream > > > distributors. I could go either way on this. > > > > Writing and locks the LE MSRs effectively needs to be done before > > running the bootloader/kernel/etc... Delaying activation would > > require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since > > IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > > > > > I know this plan is more work for everyone involved, but I think it > > > manages to actually maximize both security and freedom. > > > > > > [0]: details here - > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > > > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > > > wrote: > > > > > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > > > hardware and I > > > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > > > after boot > > > > > > > like this: > > > > > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > > > MSR 0x8c 0x20180620 > > > > > > > MSR 0x8d 0x20180620 > > > > > > > MSR 0x8e 0x20180620 > > > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug > > > > > > > of course. > > > > > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > > > non-Intel > > > > > > > values, I'm very much in favor of Nathaniels proposal to treat > > > > > > > the launch > > > > > > > enclave like any other firmware blob. > > > > > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > > > with bit 0 set. Until SGX is activated, the SGX related bits
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 05:00:05PM -0400, Nathaniel McCallum wrote: > On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson > wrote: > > > > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > > > If this is acceptable for everyone, my hope is the following: > > > > > > 1. Intel would split the existing code into one of the following > > > schemas (I don't care which): > > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > > launch enclave > > > B. two parts: UEFI module (including launch enclave) and FLC-only > > > kernel driver > > > > To make sure I understand correctly... > > > > The UEFI module would lock the LE MSRs with a public key hardcoded > > into both the UEFI module and the kernel at build time? > > > > And for the kernel, it would only load its SGX driver if FLC is > > supported and the MSRs are locked to the expected key? > > > > IIUC, this approach will cause problems for virtualization. Running > > VMs with different LE keys would require the bare metal firmware to > > configure the LE MSRs to be unlocked, which would effectively make > > using SGX in the host OS mutually exlusive with exposing SGX to KVM > > guests. Theoretically it would be possible for KVM to emulate the > > guest's LE and use the host's LE to generate EINIT tokens, but > > emulating an enclave would likely require a massive amount of code > > and/or complexity. > > How is this different from any other scenario where you lock the LE > MSRs? Unless Intel provides hardware support between the LE MSRs and > the VMX instructions, I don't see any way around this besides letting > any launch enclave run. It's not. All prior discussions have effectively required unlocked MSRs, so that's my baseline. > > > 2. Intel would release a reproducible build of the GPL UEFI module > > > sources signed with a SecureBoot trusted key and provide an > > > acceptable[0] binary redistribution license. > > > > > > 3. The kernel community would agree to merge the kernel driver given > > > the above criteria (and, obviously, acceptable kernel code). > > > > > > The question of how to distribute the UEFI module and possible launch > > > enclave remains open. I see two options: independent distribution and > > > bundling it in linux-firmware. The former may be a better > > > technological fit since the UEFI module will likely need to be run > > > before the kernel (and the boot loader; and shim). However, the latter > > > has the benefit of already being a well-known entity to our downstream > > > distributors. I could go either way on this. > > > > Writing and locks the LE MSRs effectively needs to be done before > > running the bootloader/kernel/etc... Delaying activation would > > require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since > > IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > > > > > I know this plan is more work for everyone involved, but I think it > > > manages to actually maximize both security and freedom. > > > > > > [0]: details here - > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > > > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > > > wrote: > > > > > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > > > hardware and I > > > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > > > after boot > > > > > > > like this: > > > > > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > > > MSR 0x8c 0x20180620 > > > > > > > MSR 0x8d 0x20180620 > > > > > > > MSR 0x8e 0x20180620 > > > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug > > > > > > > of course. > > > > > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > > > non-Intel > > > > > > > values, I'm very much in favor of Nathaniels proposal to treat > > > > > > > the launch > > > > > > > enclave like any other firmware blob. > > > > > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > > > with bit 0 set. Until SGX is activated, the SGX related bits
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 11:45 AM Andy Lutomirski wrote: > > On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen > wrote: > > > > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > > > This implies that it should be possible to create MSR activation (and > > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > > would still get to manage who has access to /dev/sgx and other > > > important non-cryptographic policy details. Users would still be able > > > to control the cryptographic policy details (via BIOS Secure Boot > > > configuration that exists today). Distributions could still control > > > cryptographic policy details via signing of the UEFI module with their > > > own Secure Boot key (or using something like shim). The UEFI module > > > (and possibly the external launch enclave) could be distributed via > > > linux-firmware. > > > > > > Andy/Neil, does this work for you? > > > > Nothing against having UEFI module for MSR activation step. > > > > And we would move the existing in-kernel LE to firmware so that it is > > avaible for locked-in-to-non-Intel-values case? > > > > This is a hell of a lot of complexity. To get it right we'd need an > actual formal spec of what firmware is supposed to do and how it > integrates with the kernel, and we'd need a reason why it's useful. What do you want the kernel's behavior to be in the case where an FLC CPU is present, but the MSRs have been locked by the BIOS? Because I think the workflow for the UEFI module idea is the same. > I'm personally rather strongly in favor of the vastly simpler model in > which we first merge SGX without LE support at all. Instead we use > the approach where we just twiddle the MSRs to launch normal enclaves > without an init token at all, which is probably considerably faster > and will remove several thousand lines of code. If and when a bona > fide use case for LE support shows up, we can work out the details and > merge it. I'm also okay with an incremental approach, BTW. I just want us to think through the issues. And I do think that SGX root kits are a serious threat. But I'm willing to move in stages. In fact, if we can merge something without any LE support faster, I'm in favor of doing so. > Right now, we're talking about a lot of design considerations, a lot > of interoperability considerations, and a lot of code to support a use > case that doesn't clearly exist. I agree.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 11:45 AM Andy Lutomirski wrote: > > On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen > wrote: > > > > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > > > This implies that it should be possible to create MSR activation (and > > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > > would still get to manage who has access to /dev/sgx and other > > > important non-cryptographic policy details. Users would still be able > > > to control the cryptographic policy details (via BIOS Secure Boot > > > configuration that exists today). Distributions could still control > > > cryptographic policy details via signing of the UEFI module with their > > > own Secure Boot key (or using something like shim). The UEFI module > > > (and possibly the external launch enclave) could be distributed via > > > linux-firmware. > > > > > > Andy/Neil, does this work for you? > > > > Nothing against having UEFI module for MSR activation step. > > > > And we would move the existing in-kernel LE to firmware so that it is > > avaible for locked-in-to-non-Intel-values case? > > > > This is a hell of a lot of complexity. To get it right we'd need an > actual formal spec of what firmware is supposed to do and how it > integrates with the kernel, and we'd need a reason why it's useful. What do you want the kernel's behavior to be in the case where an FLC CPU is present, but the MSRs have been locked by the BIOS? Because I think the workflow for the UEFI module idea is the same. > I'm personally rather strongly in favor of the vastly simpler model in > which we first merge SGX without LE support at all. Instead we use > the approach where we just twiddle the MSRs to launch normal enclaves > without an init token at all, which is probably considerably faster > and will remove several thousand lines of code. If and when a bona > fide use case for LE support shows up, we can work out the details and > merge it. I'm also okay with an incremental approach, BTW. I just want us to think through the issues. And I do think that SGX root kits are a serious threat. But I'm willing to move in stages. In fact, if we can merge something without any LE support faster, I'm in favor of doing so. > Right now, we're talking about a lot of design considerations, a lot > of interoperability considerations, and a lot of code to support a use > case that doesn't clearly exist. I agree.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 5:28 AM Jarkko Sakkinen wrote: > > On Wed, 2018-06-20 at 12:28 -0400, 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 > > > > 2. SGX w/ FLC, looks like this: > > Intel CPU => kernel => launch enclave => enclaves > > > > 3. Andy is proposing this: > > Intel CPU => kernel => enclaves > > What if MSRs are not writable after hand over to the OS? It is a legit > configuration at least according to the SDM. It seems to me that "set the MSRs in the BIOS" and "set the MSRs in a UEFI module" are functionally equivalent.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 5:28 AM Jarkko Sakkinen wrote: > > On Wed, 2018-06-20 at 12:28 -0400, 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 > > > > 2. SGX w/ FLC, looks like this: > > Intel CPU => kernel => launch enclave => enclaves > > > > 3. Andy is proposing this: > > Intel CPU => kernel => enclaves > > What if MSRs are not writable after hand over to the OS? It is a legit > configuration at least according to the SDM. It seems to me that "set the MSRs in the BIOS" and "set the MSRs in a UEFI module" are functionally equivalent.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote: > > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum > wrote: > > > > If this is acceptable for everyone, my hope is the following: > > > > 1. Intel would split the existing code into one of the following > > schemas (I don't care which): > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > launch enclave > > B. two parts: UEFI module (including launch enclave) and FLC-only > > kernel driver > > > > 2. Intel would release a reproducible build of the GPL UEFI module > > sources signed with a SecureBoot trusted key and provide an > > acceptable[0] binary redistribution license. > > > > 3. The kernel community would agree to merge the kernel driver given > > the above criteria (and, obviously, acceptable kernel code). > > > > The question of how to distribute the UEFI module and possible launch > > enclave remains open. I see two options: independent distribution and > > bundling it in linux-firmware. The former may be a better > > technological fit since the UEFI module will likely need to be run > > before the kernel (and the boot loader; and shim). However, the latter > > has the benefit of already being a well-known entity to our downstream > > distributors. I could go either way on this. > > This is a lot of complication and effort for a gain that is not > entirely clear. Root kits and evil maid attacks are two worth considering. > I really really really do *not* want to see Intel or > anyone else start enforcing policy on which programs can and cannot > run using this mechanism. We already do this. It is called SecureBoot. > (This is exactly why non-FLC systems aren't > about to be supported upstream.) So my preference is to not merge > anything that supports this type of use case unless there is > compelling evidence that it is (a) genuinely useful, (b) will be used > to improve security and (c) won't be abused for, say, revenue > purposes. I think there are benefits for (a) and (b). I agree with you about (c). But, again, we already have SecureBoot.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote: > > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum > wrote: > > > > If this is acceptable for everyone, my hope is the following: > > > > 1. Intel would split the existing code into one of the following > > schemas (I don't care which): > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > launch enclave > > B. two parts: UEFI module (including launch enclave) and FLC-only > > kernel driver > > > > 2. Intel would release a reproducible build of the GPL UEFI module > > sources signed with a SecureBoot trusted key and provide an > > acceptable[0] binary redistribution license. > > > > 3. The kernel community would agree to merge the kernel driver given > > the above criteria (and, obviously, acceptable kernel code). > > > > The question of how to distribute the UEFI module and possible launch > > enclave remains open. I see two options: independent distribution and > > bundling it in linux-firmware. The former may be a better > > technological fit since the UEFI module will likely need to be run > > before the kernel (and the boot loader; and shim). However, the latter > > has the benefit of already being a well-known entity to our downstream > > distributors. I could go either way on this. > > This is a lot of complication and effort for a gain that is not > entirely clear. Root kits and evil maid attacks are two worth considering. > I really really really do *not* want to see Intel or > anyone else start enforcing policy on which programs can and cannot > run using this mechanism. We already do this. It is called SecureBoot. > (This is exactly why non-FLC systems aren't > about to be supported upstream.) So my preference is to not merge > anything that supports this type of use case unless there is > compelling evidence that it is (a) genuinely useful, (b) will be used > to improve security and (c) won't be abused for, say, revenue > purposes. I think there are benefits for (a) and (b). I agree with you about (c). But, again, we already have SecureBoot.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson wrote: > > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > > If this is acceptable for everyone, my hope is the following: > > > > 1. Intel would split the existing code into one of the following > > schemas (I don't care which): > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > launch enclave > > B. two parts: UEFI module (including launch enclave) and FLC-only > > kernel driver > > To make sure I understand correctly... > > The UEFI module would lock the LE MSRs with a public key hardcoded > into both the UEFI module and the kernel at build time? > > And for the kernel, it would only load its SGX driver if FLC is > supported and the MSRs are locked to the expected key? > > IIUC, this approach will cause problems for virtualization. Running > VMs with different LE keys would require the bare metal firmware to > configure the LE MSRs to be unlocked, which would effectively make > using SGX in the host OS mutually exlusive with exposing SGX to KVM > guests. Theoretically it would be possible for KVM to emulate the > guest's LE and use the host's LE to generate EINIT tokens, but > emulating an enclave would likely require a massive amount of code > and/or complexity. How is this different from any other scenario where you lock the LE MSRs? Unless Intel provides hardware support between the LE MSRs and the VMX instructions, I don't see any way around this besides letting any launch enclave run. > > 2. Intel would release a reproducible build of the GPL UEFI module > > sources signed with a SecureBoot trusted key and provide an > > acceptable[0] binary redistribution license. > > > > 3. The kernel community would agree to merge the kernel driver given > > the above criteria (and, obviously, acceptable kernel code). > > > > The question of how to distribute the UEFI module and possible launch > > enclave remains open. I see two options: independent distribution and > > bundling it in linux-firmware. The former may be a better > > technological fit since the UEFI module will likely need to be run > > before the kernel (and the boot loader; and shim). However, the latter > > has the benefit of already being a well-known entity to our downstream > > distributors. I could go either way on this. > > Writing and locks the LE MSRs effectively needs to be done before > running the bootloader/kernel/etc... Delaying activation would > require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since > IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > > > I know this plan is more work for everyone involved, but I think it > > manages to actually maximize both security and freedom. > > > > [0]: details here - > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > > wrote: > > > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > > 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. > > > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > > hardware and I > > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > > after boot > > > > > > like this: > > > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > > MSR 0x8c 0x20180620 > > > > > > MSR 0x8d 0x20180620 > > > > > > MSR 0x8e 0x20180620 > > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug > > > > > > of course. > > > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > > non-Intel > > > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > > > launch > > > > > > enclave like any other firmware blob. > > > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > > > obvious caveat is that whatever blob
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson wrote: > > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > > If this is acceptable for everyone, my hope is the following: > > > > 1. Intel would split the existing code into one of the following > > schemas (I don't care which): > > A. three parts: UEFI module, FLC-only kernel driver and user-space > > launch enclave > > B. two parts: UEFI module (including launch enclave) and FLC-only > > kernel driver > > To make sure I understand correctly... > > The UEFI module would lock the LE MSRs with a public key hardcoded > into both the UEFI module and the kernel at build time? > > And for the kernel, it would only load its SGX driver if FLC is > supported and the MSRs are locked to the expected key? > > IIUC, this approach will cause problems for virtualization. Running > VMs with different LE keys would require the bare metal firmware to > configure the LE MSRs to be unlocked, which would effectively make > using SGX in the host OS mutually exlusive with exposing SGX to KVM > guests. Theoretically it would be possible for KVM to emulate the > guest's LE and use the host's LE to generate EINIT tokens, but > emulating an enclave would likely require a massive amount of code > and/or complexity. How is this different from any other scenario where you lock the LE MSRs? Unless Intel provides hardware support between the LE MSRs and the VMX instructions, I don't see any way around this besides letting any launch enclave run. > > 2. Intel would release a reproducible build of the GPL UEFI module > > sources signed with a SecureBoot trusted key and provide an > > acceptable[0] binary redistribution license. > > > > 3. The kernel community would agree to merge the kernel driver given > > the above criteria (and, obviously, acceptable kernel code). > > > > The question of how to distribute the UEFI module and possible launch > > enclave remains open. I see two options: independent distribution and > > bundling it in linux-firmware. The former may be a better > > technological fit since the UEFI module will likely need to be run > > before the kernel (and the boot loader; and shim). However, the latter > > has the benefit of already being a well-known entity to our downstream > > distributors. I could go either way on this. > > Writing and locks the LE MSRs effectively needs to be done before > running the bootloader/kernel/etc... Delaying activation would > require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since > IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > > > I know this plan is more work for everyone involved, but I think it > > manages to actually maximize both security and freedom. > > > > [0]: details here - > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > > wrote: > > > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > > 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. > > > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > > hardware and I > > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > > after boot > > > > > > like this: > > > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > > MSR 0x8c 0x20180620 > > > > > > MSR 0x8d 0x20180620 > > > > > > MSR 0x8e 0x20180620 > > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug > > > > > > of course. > > > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > > non-Intel > > > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > > > launch > > > > > > enclave like any other firmware blob. > > > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > > > obvious caveat is that whatever blob
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen wrote: > > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > > This implies that it should be possible to create MSR activation (and > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > would still get to manage who has access to /dev/sgx and other > > important non-cryptographic policy details. Users would still be able > > to control the cryptographic policy details (via BIOS Secure Boot > > configuration that exists today). Distributions could still control > > cryptographic policy details via signing of the UEFI module with their > > own Secure Boot key (or using something like shim). The UEFI module > > (and possibly the external launch enclave) could be distributed via > > linux-firmware. > > > > Andy/Neil, does this work for you? > > Nothing against having UEFI module for MSR activation step. > > And we would move the existing in-kernel LE to firmware so that it is > avaible for locked-in-to-non-Intel-values case? > This is a hell of a lot of complexity. To get it right we'd need an actual formal spec of what firmware is supposed to do and how it integrates with the kernel, and we'd need a reason why it's useful. I'm personally rather strongly in favor of the vastly simpler model in which we first merge SGX without LE support at all. Instead we use the approach where we just twiddle the MSRs to launch normal enclaves without an init token at all, which is probably considerably faster and will remove several thousand lines of code. If and when a bona fide use case for LE support shows up, we can work out the details and merge it. Right now, we're talking about a lot of design considerations, a lot of interoperability considerations, and a lot of code to support a use case that doesn't clearly exist. --Andy
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen wrote: > > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > > This implies that it should be possible to create MSR activation (and > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > would still get to manage who has access to /dev/sgx and other > > important non-cryptographic policy details. Users would still be able > > to control the cryptographic policy details (via BIOS Secure Boot > > configuration that exists today). Distributions could still control > > cryptographic policy details via signing of the UEFI module with their > > own Secure Boot key (or using something like shim). The UEFI module > > (and possibly the external launch enclave) could be distributed via > > linux-firmware. > > > > Andy/Neil, does this work for you? > > Nothing against having UEFI module for MSR activation step. > > And we would move the existing in-kernel LE to firmware so that it is > avaible for locked-in-to-non-Intel-values case? > This is a hell of a lot of complexity. To get it right we'd need an actual formal spec of what firmware is supposed to do and how it integrates with the kernel, and we'd need a reason why it's useful. I'm personally rather strongly in favor of the vastly simpler model in which we first merge SGX without LE support at all. Instead we use the approach where we just twiddle the MSRs to launch normal enclaves without an init token at all, which is probably considerably faster and will remove several thousand lines of code. If and when a bona fide use case for LE support shows up, we can work out the details and merge it. Right now, we're talking about a lot of design considerations, a lot of interoperability considerations, and a lot of code to support a use case that doesn't clearly exist. --Andy
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > This implies that it should be possible to create MSR activation (and > an embedded launch enclave?) entirely as a UEFI module. The kernel > would still get to manage who has access to /dev/sgx and other > important non-cryptographic policy details. Users would still be able > to control the cryptographic policy details (via BIOS Secure Boot > configuration that exists today). Distributions could still control > cryptographic policy details via signing of the UEFI module with their > own Secure Boot key (or using something like shim). The UEFI module > (and possibly the external launch enclave) could be distributed via > linux-firmware. > > Andy/Neil, does this work for you? Nothing against having UEFI module for MSR activation step. And we would move the existing in-kernel LE to firmware so that it is avaible for locked-in-to-non-Intel-values case? /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote: > This implies that it should be possible to create MSR activation (and > an embedded launch enclave?) entirely as a UEFI module. The kernel > would still get to manage who has access to /dev/sgx and other > important non-cryptographic policy details. Users would still be able > to control the cryptographic policy details (via BIOS Secure Boot > configuration that exists today). Distributions could still control > cryptographic policy details via signing of the UEFI module with their > own Secure Boot key (or using something like shim). The UEFI module > (and possibly the external launch enclave) could be distributed via > linux-firmware. > > Andy/Neil, does this work for you? Nothing against having UEFI module for MSR activation step. And we would move the existing in-kernel LE to firmware so that it is avaible for locked-in-to-non-Intel-values case? /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, 2018-06-20 at 12:28 -0400, 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 > > 2. SGX w/ FLC, looks like this: > Intel CPU => kernel => launch enclave => enclaves > > 3. Andy is proposing this: > Intel CPU => kernel => enclaves What if MSRs are not writable after hand over to the OS? It is a legit configuration at least according to the SDM. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, 2018-06-20 at 12:28 -0400, 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 > > 2. SGX w/ FLC, looks like this: > Intel CPU => kernel => launch enclave => enclaves > > 3. Andy is proposing this: > Intel CPU => kernel => enclaves What if MSRs are not writable after hand over to the OS? It is a legit configuration at least according to the SDM. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum wrote: > > If this is acceptable for everyone, my hope is the following: > > 1. Intel would split the existing code into one of the following > schemas (I don't care which): > A. three parts: UEFI module, FLC-only kernel driver and user-space > launch enclave > B. two parts: UEFI module (including launch enclave) and FLC-only > kernel driver > > 2. Intel would release a reproducible build of the GPL UEFI module > sources signed with a SecureBoot trusted key and provide an > acceptable[0] binary redistribution license. > > 3. The kernel community would agree to merge the kernel driver given > the above criteria (and, obviously, acceptable kernel code). > > The question of how to distribute the UEFI module and possible launch > enclave remains open. I see two options: independent distribution and > bundling it in linux-firmware. The former may be a better > technological fit since the UEFI module will likely need to be run > before the kernel (and the boot loader; and shim). However, the latter > has the benefit of already being a well-known entity to our downstream > distributors. I could go either way on this. This is a lot of complication and effort for a gain that is not entirely clear. I really really really do *not* want to see Intel or anyone else start enforcing policy on which programs can and cannot run using this mechanism. (This is exactly why non-FLC systems aren't about to be supported upstream.) So my preference is to not merge anything that supports this type of use case unless there is compelling evidence that it is (a) genuinely useful, (b) will be used to improve security and (c) won't be abused for, say, revenue purposes. --Andy
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum wrote: > > If this is acceptable for everyone, my hope is the following: > > 1. Intel would split the existing code into one of the following > schemas (I don't care which): > A. three parts: UEFI module, FLC-only kernel driver and user-space > launch enclave > B. two parts: UEFI module (including launch enclave) and FLC-only > kernel driver > > 2. Intel would release a reproducible build of the GPL UEFI module > sources signed with a SecureBoot trusted key and provide an > acceptable[0] binary redistribution license. > > 3. The kernel community would agree to merge the kernel driver given > the above criteria (and, obviously, acceptable kernel code). > > The question of how to distribute the UEFI module and possible launch > enclave remains open. I see two options: independent distribution and > bundling it in linux-firmware. The former may be a better > technological fit since the UEFI module will likely need to be run > before the kernel (and the boot loader; and shim). However, the latter > has the benefit of already being a well-known entity to our downstream > distributors. I could go either way on this. This is a lot of complication and effort for a gain that is not entirely clear. I really really really do *not* want to see Intel or anyone else start enforcing policy on which programs can and cannot run using this mechanism. (This is exactly why non-FLC systems aren't about to be supported upstream.) So my preference is to not merge anything that supports this type of use case unless there is compelling evidence that it is (a) genuinely useful, (b) will be used to improve security and (c) won't be abused for, say, revenue purposes. --Andy
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > If this is acceptable for everyone, my hope is the following: > > 1. Intel would split the existing code into one of the following > schemas (I don't care which): > A. three parts: UEFI module, FLC-only kernel driver and user-space > launch enclave > B. two parts: UEFI module (including launch enclave) and FLC-only > kernel driver To make sure I understand correctly... The UEFI module would lock the LE MSRs with a public key hardcoded into both the UEFI module and the kernel at build time? And for the kernel, it would only load its SGX driver if FLC is supported and the MSRs are locked to the expected key? IIUC, this approach will cause problems for virtualization. Running VMs with different LE keys would require the bare metal firmware to configure the LE MSRs to be unlocked, which would effectively make using SGX in the host OS mutually exlusive with exposing SGX to KVM guests. Theoretically it would be possible for KVM to emulate the guest's LE and use the host's LE to generate EINIT tokens, but emulating an enclave would likely require a massive amount of code and/or complexity. > 2. Intel would release a reproducible build of the GPL UEFI module > sources signed with a SecureBoot trusted key and provide an > acceptable[0] binary redistribution license. > > 3. The kernel community would agree to merge the kernel driver given > the above criteria (and, obviously, acceptable kernel code). > > The question of how to distribute the UEFI module and possible launch > enclave remains open. I see two options: independent distribution and > bundling it in linux-firmware. The former may be a better > technological fit since the UEFI module will likely need to be run > before the kernel (and the boot loader; and shim). However, the latter > has the benefit of already being a well-known entity to our downstream > distributors. I could go either way on this. Writing and locks the LE MSRs effectively needs to be done before running the bootloader/kernel/etc... Delaying activation would require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > I know this plan is more work for everyone involved, but I think it > manages to actually maximize both security and freedom. > > [0]: details here - > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > wrote: > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > 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. > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > hardware and I > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > after boot > > > > > like this: > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > MSR 0x8c 0x20180620 > > > > > MSR 0x8d 0x20180620 > > > > > MSR 0x8e 0x20180620 > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > > > course. > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > non-Intel > > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > > launch > > > > > enclave like any other firmware blob. > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > > obvious caveat is that whatever blob is used to write the MSRs would > > > > need be executed prior to activation. > > > > > > This implies that it should be possible to create MSR activation (and > > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > > would still get to manage who has access to /dev/sgx and other > > > important non-cryptographic policy details. Users would still be able > > > to control the cryptographic policy details (via BIOS Secure Boot > > > configuration that
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote: > If this is acceptable for everyone, my hope is the following: > > 1. Intel would split the existing code into one of the following > schemas (I don't care which): > A. three parts: UEFI module, FLC-only kernel driver and user-space > launch enclave > B. two parts: UEFI module (including launch enclave) and FLC-only > kernel driver To make sure I understand correctly... The UEFI module would lock the LE MSRs with a public key hardcoded into both the UEFI module and the kernel at build time? And for the kernel, it would only load its SGX driver if FLC is supported and the MSRs are locked to the expected key? IIUC, this approach will cause problems for virtualization. Running VMs with different LE keys would require the bare metal firmware to configure the LE MSRs to be unlocked, which would effectively make using SGX in the host OS mutually exlusive with exposing SGX to KVM guests. Theoretically it would be possible for KVM to emulate the guest's LE and use the host's LE to generate EINIT tokens, but emulating an enclave would likely require a massive amount of code and/or complexity. > 2. Intel would release a reproducible build of the GPL UEFI module > sources signed with a SecureBoot trusted key and provide an > acceptable[0] binary redistribution license. > > 3. The kernel community would agree to merge the kernel driver given > the above criteria (and, obviously, acceptable kernel code). > > The question of how to distribute the UEFI module and possible launch > enclave remains open. I see two options: independent distribution and > bundling it in linux-firmware. The former may be a better > technological fit since the UEFI module will likely need to be run > before the kernel (and the boot loader; and shim). However, the latter > has the benefit of already being a well-known entity to our downstream > distributors. I could go either way on this. Writing and locks the LE MSRs effectively needs to be done before running the bootloader/kernel/etc... Delaying activation would require, at a minimum, leaving IA32_FEATURE_CONTROL unlocked since IA32_FEATURE_CONTROL's SGX bits can't be set until SGX is activated. > I know this plan is more work for everyone involved, but I think it > manages to actually maximize both security and freedom. > > [0]: details here - > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 > On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > > wrote: > > > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > > 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. > > > > > > > > > > Actually, this might be a documentation bug. I have some test > > > > > hardware and I > > > > > was able to configure the MSRs in the BIOS and then read the MSRs > > > > > after boot > > > > > like this: > > > > > > > > > > MSR 0x3a 0x00040005 > > > > > MSR 0x8c 0x20180620 > > > > > MSR 0x8d 0x20180620 > > > > > MSR 0x8e 0x20180620 > > > > > MSR 0x8f 0x20180620 > > > > > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > > > course. > > > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > > non-Intel > > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > > launch > > > > > enclave like any other firmware blob. > > > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > > obvious caveat is that whatever blob is used to write the MSRs would > > > > need be executed prior to activation. > > > > > > This implies that it should be possible to create MSR activation (and > > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > > would still get to manage who has access to /dev/sgx and other > > > important non-cryptographic policy details. Users would still be able > > > to control the cryptographic policy details (via BIOS Secure Boot > > > configuration that
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
If this is acceptable for everyone, my hope is the following: 1. Intel would split the existing code into one of the following schemas (I don't care which): A. three parts: UEFI module, FLC-only kernel driver and user-space launch enclave B. two parts: UEFI module (including launch enclave) and FLC-only kernel driver 2. Intel would release a reproducible build of the GPL UEFI module sources signed with a SecureBoot trusted key and provide an acceptable[0] binary redistribution license. 3. The kernel community would agree to merge the kernel driver given the above criteria (and, obviously, acceptable kernel code). The question of how to distribute the UEFI module and possible launch enclave remains open. I see two options: independent distribution and bundling it in linux-firmware. The former may be a better technological fit since the UEFI module will likely need to be run before the kernel (and the boot loader; and shim). However, the latter has the benefit of already being a well-known entity to our downstream distributors. I could go either way on this. I know this plan is more work for everyone involved, but I think it manages to actually maximize both security and freedom. [0]: details here - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > wrote: > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > 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. > > > > > > > > Actually, this might be a documentation bug. I have some test hardware > > > > and I > > > > was able to configure the MSRs in the BIOS and then read the MSRs after > > > > boot > > > > like this: > > > > > > > > MSR 0x3a 0x00040005 > > > > MSR 0x8c 0x20180620 > > > > MSR 0x8d 0x20180620 > > > > MSR 0x8e 0x20180620 > > > > MSR 0x8f 0x20180620 > > > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > > course. > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > non-Intel > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > launch > > > > enclave like any other firmware blob. > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > obvious caveat is that whatever blob is used to write the MSRs would > > > need be executed prior to activation. > > > > This implies that it should be possible to create MSR activation (and > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > would still get to manage who has access to /dev/sgx and other > > important non-cryptographic policy details. Users would still be able > > to control the cryptographic policy details (via BIOS Secure Boot > > configuration that exists today). Distributions could still control > > cryptographic policy details via signing of the UEFI module with their > > own Secure Boot key (or using something like shim). The UEFI module > > (and possibly the external launch enclave) could be distributed via > > linux-firmware. > > > > Andy/Neil, does this work for you? > > > I need some time to digest it. Who in your mind is writing the UEFI module. > Is > that the firmware vendor or IHV? > > Neil > > > > As for the SDM, it's a documentation... omission? SGX activation > > > is intentionally omitted from the SDM. The intended usage model is > > > that firmware will always do the activation (if it wants SGX enabled), > > > i.e. post-firmware software will only ever "see" SGX as disabled or > > > in the fully activated state, and so the SDM doesn't describe SGX > > > behavior prior to activation. I believe the activation process, or > > > at least what is required from firmware, is documented in the BIOS > > > writer's guide. > > > > > > > Jethro Beekman | Fortanix > > > > > > > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
If this is acceptable for everyone, my hope is the following: 1. Intel would split the existing code into one of the following schemas (I don't care which): A. three parts: UEFI module, FLC-only kernel driver and user-space launch enclave B. two parts: UEFI module (including launch enclave) and FLC-only kernel driver 2. Intel would release a reproducible build of the GPL UEFI module sources signed with a SecureBoot trusted key and provide an acceptable[0] binary redistribution license. 3. The kernel community would agree to merge the kernel driver given the above criteria (and, obviously, acceptable kernel code). The question of how to distribute the UEFI module and possible launch enclave remains open. I see two options: independent distribution and bundling it in linux-firmware. The former may be a better technological fit since the UEFI module will likely need to be run before the kernel (and the boot loader; and shim). However, the latter has the benefit of already being a well-known entity to our downstream distributors. I could go either way on this. I know this plan is more work for everyone involved, but I think it manages to actually maximize both security and freedom. [0]: details here - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19 On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote: > > On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > > wrote: > > > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > > 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. > > > > > > > > Actually, this might be a documentation bug. I have some test hardware > > > > and I > > > > was able to configure the MSRs in the BIOS and then read the MSRs after > > > > boot > > > > like this: > > > > > > > > MSR 0x3a 0x00040005 > > > > MSR 0x8c 0x20180620 > > > > MSR 0x8d 0x20180620 > > > > MSR 0x8e 0x20180620 > > > > MSR 0x8f 0x20180620 > > > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > > course. > > > > > > > > If it is indeed possible to configure AND lock the MSR values to > > > > non-Intel > > > > values, I'm very much in favor of Nathaniels proposal to treat the > > > > launch > > > > enclave like any other firmware blob. > > > > > > It's not a CPU or documentation bug (though the latter is arguable). > > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > > with bit 0 set. Until SGX is activated, the SGX related bits in > > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > > the LE hash MSRs are fully writable prior to activation, e.g. to > > > allow firmware to lock down the LE key with a non-Intel value. > > > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > > obvious caveat is that whatever blob is used to write the MSRs would > > > need be executed prior to activation. > > > > This implies that it should be possible to create MSR activation (and > > an embedded launch enclave?) entirely as a UEFI module. The kernel > > would still get to manage who has access to /dev/sgx and other > > important non-cryptographic policy details. Users would still be able > > to control the cryptographic policy details (via BIOS Secure Boot > > configuration that exists today). Distributions could still control > > cryptographic policy details via signing of the UEFI module with their > > own Secure Boot key (or using something like shim). The UEFI module > > (and possibly the external launch enclave) could be distributed via > > linux-firmware. > > > > Andy/Neil, does this work for you? > > > I need some time to digest it. Who in your mind is writing the UEFI module. > Is > that the firmware vendor or IHV? > > Neil > > > > As for the SDM, it's a documentation... omission? SGX activation > > > is intentionally omitted from the SDM. The intended usage model is > > > that firmware will always do the activation (if it wants SGX enabled), > > > i.e. post-firmware software will only ever "see" SGX as disabled or > > > in the fully activated state, and so the SDM doesn't describe SGX > > > behavior prior to activation. I believe the activation process, or > > > at least what is required from firmware, is documented in the BIOS > > > writer's guide. > > > > > > > Jethro Beekman | Fortanix > > > > > > > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > wrote: > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > 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. > > > > > > Actually, this might be a documentation bug. I have some test hardware > > > and I > > > was able to configure the MSRs in the BIOS and then read the MSRs after > > > boot > > > like this: > > > > > > MSR 0x3a 0x00040005 > > > MSR 0x8c 0x20180620 > > > MSR 0x8d 0x20180620 > > > MSR 0x8e 0x20180620 > > > MSR 0x8f 0x20180620 > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > course. > > > > > > If it is indeed possible to configure AND lock the MSR values to non-Intel > > > values, I'm very much in favor of Nathaniels proposal to treat the launch > > > enclave like any other firmware blob. > > > > It's not a CPU or documentation bug (though the latter is arguable). > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > with bit 0 set. Until SGX is activated, the SGX related bits in > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > the LE hash MSRs are fully writable prior to activation, e.g. to > > allow firmware to lock down the LE key with a non-Intel value. > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > obvious caveat is that whatever blob is used to write the MSRs would > > need be executed prior to activation. > > This implies that it should be possible to create MSR activation (and > an embedded launch enclave?) entirely as a UEFI module. The kernel > would still get to manage who has access to /dev/sgx and other > important non-cryptographic policy details. Users would still be able > to control the cryptographic policy details (via BIOS Secure Boot > configuration that exists today). Distributions could still control > cryptographic policy details via signing of the UEFI module with their > own Secure Boot key (or using something like shim). The UEFI module > (and possibly the external launch enclave) could be distributed via > linux-firmware. > > Andy/Neil, does this work for you? > I need some time to digest it. Who in your mind is writing the UEFI module. Is that the firmware vendor or IHV? Neil > > As for the SDM, it's a documentation... omission? SGX activation > > is intentionally omitted from the SDM. The intended usage model is > > that firmware will always do the activation (if it wants SGX enabled), > > i.e. post-firmware software will only ever "see" SGX as disabled or > > in the fully activated state, and so the SDM doesn't describe SGX > > behavior prior to activation. I believe the activation process, or > > at least what is required from firmware, is documented in the BIOS > > writer's guide. > > > > > Jethro Beekman | Fortanix > > > > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > wrote: > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > 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. > > > > > > Actually, this might be a documentation bug. I have some test hardware > > > and I > > > was able to configure the MSRs in the BIOS and then read the MSRs after > > > boot > > > like this: > > > > > > MSR 0x3a 0x00040005 > > > MSR 0x8c 0x20180620 > > > MSR 0x8d 0x20180620 > > > MSR 0x8e 0x20180620 > > > MSR 0x8f 0x20180620 > > > > > > Since this is not production hardware, it could also be a CPU bug of > > > course. > > > > > > If it is indeed possible to configure AND lock the MSR values to non-Intel > > > values, I'm very much in favor of Nathaniels proposal to treat the launch > > > enclave like any other firmware blob. > > > > It's not a CPU or documentation bug (though the latter is arguable). > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > with bit 0 set. Until SGX is activated, the SGX related bits in > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > the LE hash MSRs are fully writable prior to activation, e.g. to > > allow firmware to lock down the LE key with a non-Intel value. > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > obvious caveat is that whatever blob is used to write the MSRs would > > need be executed prior to activation. > > This implies that it should be possible to create MSR activation (and > an embedded launch enclave?) entirely as a UEFI module. The kernel > would still get to manage who has access to /dev/sgx and other > important non-cryptographic policy details. Users would still be able > to control the cryptographic policy details (via BIOS Secure Boot > configuration that exists today). Distributions could still control > cryptographic policy details via signing of the UEFI module with their > own Secure Boot key (or using something like shim). The UEFI module > (and possibly the external launch enclave) could be distributed via > linux-firmware. > > Andy/Neil, does this work for you? > I need some time to digest it. Who in your mind is writing the UEFI module. Is that the firmware vendor or IHV? Neil > > As for the SDM, it's a documentation... omission? SGX activation > > is intentionally omitted from the SDM. The intended usage model is > > that firmware will always do the activation (if it wants SGX enabled), > > i.e. post-firmware software will only ever "see" SGX as disabled or > > in the fully activated state, and so the SDM doesn't describe SGX > > behavior prior to activation. I believe the activation process, or > > at least what is required from firmware, is documented in the BIOS > > writer's guide. > > > > > Jethro Beekman | Fortanix > > > > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson wrote: > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > 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. > > > > Actually, this might be a documentation bug. I have some test hardware and I > > was able to configure the MSRs in the BIOS and then read the MSRs after boot > > like this: > > > > MSR 0x3a 0x00040005 > > MSR 0x8c 0x20180620 > > MSR 0x8d 0x20180620 > > MSR 0x8e 0x20180620 > > MSR 0x8f 0x20180620 > > > > Since this is not production hardware, it could also be a CPU bug of course. > > > > If it is indeed possible to configure AND lock the MSR values to non-Intel > > values, I'm very much in favor of Nathaniels proposal to treat the launch > > enclave like any other firmware blob. > > It's not a CPU or documentation bug (though the latter is arguable). > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > with bit 0 set. Until SGX is activated, the SGX related bits in > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > the LE hash MSRs are fully writable prior to activation, e.g. to > allow firmware to lock down the LE key with a non-Intel value. > > So yes, it's possible to lock the MSRs to a non-Intel value. The > obvious caveat is that whatever blob is used to write the MSRs would > need be executed prior to activation. This implies that it should be possible to create MSR activation (and an embedded launch enclave?) entirely as a UEFI module. The kernel would still get to manage who has access to /dev/sgx and other important non-cryptographic policy details. Users would still be able to control the cryptographic policy details (via BIOS Secure Boot configuration that exists today). Distributions could still control cryptographic policy details via signing of the UEFI module with their own Secure Boot key (or using something like shim). The UEFI module (and possibly the external launch enclave) could be distributed via linux-firmware. Andy/Neil, does this work for you? > As for the SDM, it's a documentation... omission? SGX activation > is intentionally omitted from the SDM. The intended usage model is > that firmware will always do the activation (if it wants SGX enabled), > i.e. post-firmware software will only ever "see" SGX as disabled or > in the fully activated state, and so the SDM doesn't describe SGX > behavior prior to activation. I believe the activation process, or > at least what is required from firmware, is documented in the BIOS > writer's guide. > > > Jethro Beekman | Fortanix > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson wrote: > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > 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. > > > > Actually, this might be a documentation bug. I have some test hardware and I > > was able to configure the MSRs in the BIOS and then read the MSRs after boot > > like this: > > > > MSR 0x3a 0x00040005 > > MSR 0x8c 0x20180620 > > MSR 0x8d 0x20180620 > > MSR 0x8e 0x20180620 > > MSR 0x8f 0x20180620 > > > > Since this is not production hardware, it could also be a CPU bug of course. > > > > If it is indeed possible to configure AND lock the MSR values to non-Intel > > values, I'm very much in favor of Nathaniels proposal to treat the launch > > enclave like any other firmware blob. > > It's not a CPU or documentation bug (though the latter is arguable). > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > with bit 0 set. Until SGX is activated, the SGX related bits in > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > the LE hash MSRs are fully writable prior to activation, e.g. to > allow firmware to lock down the LE key with a non-Intel value. > > So yes, it's possible to lock the MSRs to a non-Intel value. The > obvious caveat is that whatever blob is used to write the MSRs would > need be executed prior to activation. This implies that it should be possible to create MSR activation (and an embedded launch enclave?) entirely as a UEFI module. The kernel would still get to manage who has access to /dev/sgx and other important non-cryptographic policy details. Users would still be able to control the cryptographic policy details (via BIOS Secure Boot configuration that exists today). Distributions could still control cryptographic policy details via signing of the UEFI module with their own Secure Boot key (or using something like shim). The UEFI module (and possibly the external launch enclave) could be distributed via linux-firmware. Andy/Neil, does this work for you? > As for the SDM, it's a documentation... omission? SGX activation > is intentionally omitted from the SDM. The intended usage model is > that firmware will always do the activation (if it wants SGX enabled), > i.e. post-firmware software will only ever "see" SGX as disabled or > in the fully activated state, and so the SDM doesn't describe SGX > behavior prior to activation. I believe the activation process, or > at least what is required from firmware, is documented in the BIOS > writer's guide. > > > Jethro Beekman | Fortanix > > > >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 2:16 PM Jethro Beekman wrote: > > 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 I get what you mean. But it wasn't what I intended. I'm referring to cryptographic policy. While it is true that the kernel would provide hardware support and would still enforce other non-cryptographic policy under this model (such as filesystem permissions to /dev/sgx), the kernel doesn't verify signatures or pick the key used to verify signatures. The Intel CPU validates the signature of the launch enclave using a hard-coded key. Since the kernel doesn't get to pick the key, it has no say in the cryptographic policy. > > 2. SGX w/ FLC, looks like this: > >Intel CPU => kernel => launch enclave => enclaves In this case, the kernel picks the key used to verify the signature of the LE and writes it to the appropriate MSRs. So it has a say in the policy chain. > > 3. Andy is proposing this: > >Intel CPU => kernel => enclaves In this case, the kernel basically throws away the concept of LEs based on the fact that proposal #2 doesn't actually reduce the attack surface and therefore adds complexity without security. So the kernel takes over the evaluation of the cryptographic policy. > > 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 >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 2:16 PM Jethro Beekman wrote: > > 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 I get what you mean. But it wasn't what I intended. I'm referring to cryptographic policy. While it is true that the kernel would provide hardware support and would still enforce other non-cryptographic policy under this model (such as filesystem permissions to /dev/sgx), the kernel doesn't verify signatures or pick the key used to verify signatures. The Intel CPU validates the signature of the launch enclave using a hard-coded key. Since the kernel doesn't get to pick the key, it has no say in the cryptographic policy. > > 2. SGX w/ FLC, looks like this: > >Intel CPU => kernel => launch enclave => enclaves In this case, the kernel picks the key used to verify the signature of the LE and writes it to the appropriate MSRs. So it has a say in the policy chain. > > 3. Andy is proposing this: > >Intel CPU => kernel => enclaves In this case, the kernel basically throws away the concept of LEs based on the fact that proposal #2 doesn't actually reduce the attack surface and therefore adds complexity without security. So the kernel takes over the evaluation of the cryptographic policy. > > 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 >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > On 2018-06-20 11:16, Jethro Beekman wrote: > > > 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. > > Actually, this might be a documentation bug. I have some test hardware and I > was able to configure the MSRs in the BIOS and then read the MSRs after boot > like this: > > MSR 0x3a 0x00040005 > MSR 0x8c 0x20180620 > MSR 0x8d 0x20180620 > MSR 0x8e 0x20180620 > MSR 0x8f 0x20180620 > > Since this is not production hardware, it could also be a CPU bug of course. > > If it is indeed possible to configure AND lock the MSR values to non-Intel > values, I'm very much in favor of Nathaniels proposal to treat the launch > enclave like any other firmware blob. It's not a CPU or documentation bug (though the latter is arguable). SGX has an activation step that is triggered by doing a WRMSR(0x7a) with bit 0 set. Until SGX is activated, the SGX related bits in IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, the LE hash MSRs are fully writable prior to activation, e.g. to allow firmware to lock down the LE key with a non-Intel value. So yes, it's possible to lock the MSRs to a non-Intel value. The obvious caveat is that whatever blob is used to write the MSRs would need be executed prior to activation. As for the SDM, it's a documentation... omission? SGX activation is intentionally omitted from the SDM. The intended usage model is that firmware will always do the activation (if it wants SGX enabled), i.e. post-firmware software will only ever "see" SGX as disabled or in the fully activated state, and so the SDM doesn't describe SGX behavior prior to activation. I believe the activation process, or at least what is required from firmware, is documented in the BIOS writer's guide. > Jethro Beekman | Fortanix >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > On 2018-06-20 11:16, Jethro Beekman wrote: > > > 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. > > Actually, this might be a documentation bug. I have some test hardware and I > was able to configure the MSRs in the BIOS and then read the MSRs after boot > like this: > > MSR 0x3a 0x00040005 > MSR 0x8c 0x20180620 > MSR 0x8d 0x20180620 > MSR 0x8e 0x20180620 > MSR 0x8f 0x20180620 > > Since this is not production hardware, it could also be a CPU bug of course. > > If it is indeed possible to configure AND lock the MSR values to non-Intel > values, I'm very much in favor of Nathaniels proposal to treat the launch > enclave like any other firmware blob. It's not a CPU or documentation bug (though the latter is arguable). SGX has an activation step that is triggered by doing a WRMSR(0x7a) with bit 0 set. Until SGX is activated, the SGX related bits in IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, the LE hash MSRs are fully writable prior to activation, e.g. to allow firmware to lock down the LE key with a non-Intel value. So yes, it's possible to lock the MSRs to a non-Intel value. The obvious caveat is that whatever blob is used to write the MSRs would need be executed prior to activation. As for the SDM, it's a documentation... omission? SGX activation is intentionally omitted from the SDM. The intended usage model is that firmware will always do the activation (if it wants SGX enabled), i.e. post-firmware software will only ever "see" SGX as disabled or in the fully activated state, and so the SDM doesn't describe SGX behavior prior to activation. I believe the activation process, or at least what is required from firmware, is documented in the BIOS writer's guide. > Jethro Beekman | Fortanix >
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On 2018-06-20 11:16, Jethro Beekman wrote: > 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. Actually, this might be a documentation bug. I have some test hardware and I was able to configure the MSRs in the BIOS and then read the MSRs after boot like this: MSR 0x3a 0x00040005 MSR 0x8c 0x20180620 MSR 0x8d 0x20180620 MSR 0x8e 0x20180620 MSR 0x8f 0x20180620 Since this is not production hardware, it could also be a CPU bug of course. If it is indeed possible to configure AND lock the MSR values to non-Intel values, I'm very much in favor of Nathaniels proposal to treat the launch enclave like any other firmware blob. Jethro Beekman | Fortanix smime.p7s Description: S/MIME Cryptographic Signature
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On 2018-06-20 11:16, Jethro Beekman wrote: > 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. Actually, this might be a documentation bug. I have some test hardware and I was able to configure the MSRs in the BIOS and then read the MSRs after boot like this: MSR 0x3a 0x00040005 MSR 0x8c 0x20180620 MSR 0x8d 0x20180620 MSR 0x8e 0x20180620 MSR 0x8f 0x20180620 Since this is not production hardware, it could also be a CPU bug of course. If it is indeed possible to configure AND lock the MSR values to non-Intel values, I'm very much in favor of Nathaniels proposal to treat the launch enclave like any other firmware blob. Jethro Beekman | Fortanix smime.p7s Description: S/MIME Cryptographic Signature
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 smime.p7s Description: S/MIME Cryptographic Signature
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
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 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? 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. On Mon, Jun 18, 2018 at 5:59 PM Andy Lutomirski wrote: > > On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski > > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > > wrote: > > > > > >> > > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > > >> user > > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > > >> enclave > > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > > >> Linux > > > > > >> has full control of the enclave launch process. > > > > > >> > > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > > >> implemented by using the user space helper framework. The IPC > > > > > >> between > > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > > >> > > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > > >> points > > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE > > > > > >> public key > > > > > >> pair. The default location is: > > > > > >> > > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > > >> > > > > > >> If the default key does not exist kbuild will generate a random > > > > > >> key and > > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to > > > > > >> specify > > > > > >> the passphrase for the LE public key. > > > > > > > > > > > > It seems to me that it might be more useful to just commit a key > > > > > > pair > > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > > gained by keeping the private key private, so why not make > > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > > > Having thought about this some more, I think that you should > > > > > completely remove support for specifying a key. Provide a fixed key > > > > > pair, hard code the cache, and call it a day. If you make the key > > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > > give some illusion of security and it'll slow down operations in a VM > > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > > support a locked MSR that just happens to have the right value stays > > > > > in the kernel, then we'll risk having vendors actually ship one > > > > > distro's public key hash, and that will seriously suck. > > > > > > > > > If you hard code the key pair however, doesn't that imply that anyone > > > > can sign a > > > > user space binary as a launch enclave, and potentially gain control of > > > > the token > > > > granting process? > > > > > > Yes and no. > > > > > > First of all, the kernel driver shouldn't be allowing user code to > > > launch a launch enclave regardless of signature. I haven't gotten far > > > enough in reviewing the code to see whether that's the case, but if > > > it's not, it should be fixed before
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
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 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? 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. On Mon, Jun 18, 2018 at 5:59 PM Andy Lutomirski wrote: > > On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski > > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > > wrote: > > > > > >> > > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > > >> user > > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > > >> enclave > > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > > >> Linux > > > > > >> has full control of the enclave launch process. > > > > > >> > > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > > >> implemented by using the user space helper framework. The IPC > > > > > >> between > > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > > >> > > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > > >> points > > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE > > > > > >> public key > > > > > >> pair. The default location is: > > > > > >> > > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > > >> > > > > > >> If the default key does not exist kbuild will generate a random > > > > > >> key and > > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to > > > > > >> specify > > > > > >> the passphrase for the LE public key. > > > > > > > > > > > > It seems to me that it might be more useful to just commit a key > > > > > > pair > > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > > gained by keeping the private key private, so why not make > > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > > > Having thought about this some more, I think that you should > > > > > completely remove support for specifying a key. Provide a fixed key > > > > > pair, hard code the cache, and call it a day. If you make the key > > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > > give some illusion of security and it'll slow down operations in a VM > > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > > support a locked MSR that just happens to have the right value stays > > > > > in the kernel, then we'll risk having vendors actually ship one > > > > > distro's public key hash, and that will seriously suck. > > > > > > > > > If you hard code the key pair however, doesn't that imply that anyone > > > > can sign a > > > > user space binary as a launch enclave, and potentially gain control of > > > > the token > > > > granting process? > > > > > > Yes and no. > > > > > > First of all, the kernel driver shouldn't be allowing user code to > > > launch a launch enclave regardless of signature. I haven't gotten far > > > enough in reviewing the code to see whether that's the case, but if > > > it's not, it should be fixed before
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > wrote: > >> > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > >> enclaves. A launch token is used by EINIT to check whether the enclave > >> is authorized to launch or not. By having its own launch enclave, Linux > >> has full control of the enclave launch process. > >> > >> LE is wrapped into a user space proxy program that reads enclave > >> signatures outputs launch tokens. The kernel-side glue code is > >> implemented by using the user space helper framework. The IPC between > >> the LE proxy program and kernel is handled with an anonymous inode. > >> > >> The commit also adds enclave signing tool that is used by kbuild to > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > >> pair. The default location is: > >> > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > >> > >> If the default key does not exist kbuild will generate a random key and > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > >> the passphrase for the LE public key. > > > > It seems to me that it might be more useful to just commit a key pair > > into the kernel. As far as I know, there is no security whatsoever > > gained by keeping the private key private, so why not make > > reproducible builds easier by simply fixing the key? > > Having thought about this some more, I think that you should > completely remove support for specifying a key. Provide a fixed key > pair, hard code the cache, and call it a day. If you make the key > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > and set up their own key pair for no gain whatsoever. Instead, it'll > give some illusion of security and it'll slow down operations in a VM > guest due to swapping out the values of the MSRs. And, if the code to > support a locked MSR that just happens to have the right value stays > in the kernel, then we'll risk having vendors actually ship one > distro's public key hash, and that will seriously suck. > > I'm going to try to get this code working tomorrow. I'll keep you > posted on how that goes. Can you point me to the userspace bits (i.e. > something buildable that will run on a kernel with your patches > applied)? Sorry for some delay. I was on leave last week. The SDK supports my driver starting from 2.1 release: https://github.com/intel/linux-sgx SampleCode folder contains some trivial test code to run. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > wrote: > >> > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > >> enclaves. A launch token is used by EINIT to check whether the enclave > >> is authorized to launch or not. By having its own launch enclave, Linux > >> has full control of the enclave launch process. > >> > >> LE is wrapped into a user space proxy program that reads enclave > >> signatures outputs launch tokens. The kernel-side glue code is > >> implemented by using the user space helper framework. The IPC between > >> the LE proxy program and kernel is handled with an anonymous inode. > >> > >> The commit also adds enclave signing tool that is used by kbuild to > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > >> pair. The default location is: > >> > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > >> > >> If the default key does not exist kbuild will generate a random key and > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > >> the passphrase for the LE public key. > > > > It seems to me that it might be more useful to just commit a key pair > > into the kernel. As far as I know, there is no security whatsoever > > gained by keeping the private key private, so why not make > > reproducible builds easier by simply fixing the key? > > Having thought about this some more, I think that you should > completely remove support for specifying a key. Provide a fixed key > pair, hard code the cache, and call it a day. If you make the key > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > and set up their own key pair for no gain whatsoever. Instead, it'll > give some illusion of security and it'll slow down operations in a VM > guest due to swapping out the values of the MSRs. And, if the code to > support a locked MSR that just happens to have the right value stays > in the kernel, then we'll risk having vendors actually ship one > distro's public key hash, and that will seriously suck. > > I'm going to try to get this code working tomorrow. I'll keep you > posted on how that goes. Can you point me to the userspace bits (i.e. > something buildable that will run on a kernel with your patches > applied)? Sorry for some delay. I was on leave last week. The SDK supports my driver starting from 2.1 release: https://github.com/intel/linux-sgx SampleCode folder contains some trivial test code to run. /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 08, 2018 at 11:50:14AM -0700, Andy Lutomirski wrote: > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > wrote: > > > > The Launch Enclave (LE) generates cryptographic launch tokens for user > > enclaves. A launch token is used by EINIT to check whether the enclave > > is authorized to launch or not. By having its own launch enclave, Linux > > has full control of the enclave launch process. > > > > LE is wrapped into a user space proxy program that reads enclave > > signatures outputs launch tokens. The kernel-side glue code is > > implemented by using the user space helper framework. The IPC between > > the LE proxy program and kernel is handled with an anonymous inode. > > > > The commit also adds enclave signing tool that is used by kbuild to > > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > > pair. The default location is: > > It might be nice to use the infrastructure that Alexei added for > bpfilter (the umh_blob stuff) here, which is slated for merging in > this merge window. > > --Andy Thanks, not familiar with this work. Is there any documentation for it available? /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 08, 2018 at 11:50:14AM -0700, Andy Lutomirski wrote: > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > wrote: > > > > The Launch Enclave (LE) generates cryptographic launch tokens for user > > enclaves. A launch token is used by EINIT to check whether the enclave > > is authorized to launch or not. By having its own launch enclave, Linux > > has full control of the enclave launch process. > > > > LE is wrapped into a user space proxy program that reads enclave > > signatures outputs launch tokens. The kernel-side glue code is > > implemented by using the user space helper framework. The IPC between > > the LE proxy program and kernel is handled with an anonymous inode. > > > > The commit also adds enclave signing tool that is used by kbuild to > > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > > pair. The default location is: > > It might be nice to use the infrastructure that Alexei added for > bpfilter (the umh_blob stuff) here, which is slated for merging in > this merge window. > > --Andy Thanks, not familiar with this work. Is there any documentation for it available? /Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 18, 2018 at 02:58:59PM -0700, Andy Lutomirski wrote: > On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski > > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > > wrote: > > > > > >> > > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > > >> user > > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > > >> enclave > > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > > >> Linux > > > > > >> has full control of the enclave launch process. > > > > > >> > > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > > >> implemented by using the user space helper framework. The IPC > > > > > >> between > > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > > >> > > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > > >> points > > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE > > > > > >> public key > > > > > >> pair. The default location is: > > > > > >> > > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > > >> > > > > > >> If the default key does not exist kbuild will generate a random > > > > > >> key and > > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to > > > > > >> specify > > > > > >> the passphrase for the LE public key. > > > > > > > > > > > > It seems to me that it might be more useful to just commit a key > > > > > > pair > > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > > gained by keeping the private key private, so why not make > > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > > > Having thought about this some more, I think that you should > > > > > completely remove support for specifying a key. Provide a fixed key > > > > > pair, hard code the cache, and call it a day. If you make the key > > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > > give some illusion of security and it'll slow down operations in a VM > > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > > support a locked MSR that just happens to have the right value stays > > > > > in the kernel, then we'll risk having vendors actually ship one > > > > > distro's public key hash, and that will seriously suck. > > > > > > > > > If you hard code the key pair however, doesn't that imply that anyone > > > > can sign a > > > > user space binary as a launch enclave, and potentially gain control of > > > > the token > > > > granting process? > > > > > > Yes and no. > > > > > > First of all, the kernel driver shouldn't be allowing user code to > > > launch a launch enclave regardless of signature. I haven't gotten far > > > enough in reviewing the code to see whether that's the case, but if > > > it's not, it should be fixed before it's merged. > > > > > Ok, I agree with you here. > > > > > But keep in mind that control of the token granting process is not the > > > same thing as control over the right to launch an enclave. On systems > > > without the LE hash MSRs, Intel controls the token granting process > > > and, barring some attack, an enclave that isn't blessed by Intel can't > > > be launched. Support for that model will not be merged into upstream > > > Linux. But on systems that have the LE hash MSRs and leave them > > > unlocked, there is effectively no hardware-enforced launch control. > > > Instead we have good old kernel policy. If a user wants to launch an > > > enclave, they need to get the kernel to launch the enclave, and the > > > kernel needs to apply its policy. The patch here (the in-kernel > > > launch enclave) has a wide-open policy. > > > > > > > Right, also agree here. Systems without Flexible Launch Control are a > > non-starter, we're only considering FLC systems here > > > > > So, as a practical matter, if every distro has their own LE key and > > > keeps it totally safe, then a system that locks the MSRs to one > > > distro's key makes it quite annoying to run another distro's intel_sgx > > > driver, but there is no effect on the actual security of the system. > > > > > I agree that for systems that firmware-lock the msrs are annoying, but I > > would > > think that
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 18, 2018 at 02:58:59PM -0700, Andy Lutomirski wrote: > On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski > > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > > wrote: > > > > > >> > > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > > >> user > > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > > >> enclave > > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > > >> Linux > > > > > >> has full control of the enclave launch process. > > > > > >> > > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > > >> implemented by using the user space helper framework. The IPC > > > > > >> between > > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > > >> > > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > > >> points > > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE > > > > > >> public key > > > > > >> pair. The default location is: > > > > > >> > > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > > >> > > > > > >> If the default key does not exist kbuild will generate a random > > > > > >> key and > > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to > > > > > >> specify > > > > > >> the passphrase for the LE public key. > > > > > > > > > > > > It seems to me that it might be more useful to just commit a key > > > > > > pair > > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > > gained by keeping the private key private, so why not make > > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > > > Having thought about this some more, I think that you should > > > > > completely remove support for specifying a key. Provide a fixed key > > > > > pair, hard code the cache, and call it a day. If you make the key > > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > > give some illusion of security and it'll slow down operations in a VM > > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > > support a locked MSR that just happens to have the right value stays > > > > > in the kernel, then we'll risk having vendors actually ship one > > > > > distro's public key hash, and that will seriously suck. > > > > > > > > > If you hard code the key pair however, doesn't that imply that anyone > > > > can sign a > > > > user space binary as a launch enclave, and potentially gain control of > > > > the token > > > > granting process? > > > > > > Yes and no. > > > > > > First of all, the kernel driver shouldn't be allowing user code to > > > launch a launch enclave regardless of signature. I haven't gotten far > > > enough in reviewing the code to see whether that's the case, but if > > > it's not, it should be fixed before it's merged. > > > > > Ok, I agree with you here. > > > > > But keep in mind that control of the token granting process is not the > > > same thing as control over the right to launch an enclave. On systems > > > without the LE hash MSRs, Intel controls the token granting process > > > and, barring some attack, an enclave that isn't blessed by Intel can't > > > be launched. Support for that model will not be merged into upstream > > > Linux. But on systems that have the LE hash MSRs and leave them > > > unlocked, there is effectively no hardware-enforced launch control. > > > Instead we have good old kernel policy. If a user wants to launch an > > > enclave, they need to get the kernel to launch the enclave, and the > > > kernel needs to apply its policy. The patch here (the in-kernel > > > launch enclave) has a wide-open policy. > > > > > > > Right, also agree here. Systems without Flexible Launch Control are a > > non-starter, we're only considering FLC systems here > > > > > So, as a practical matter, if every distro has their own LE key and > > > keeps it totally safe, then a system that locks the MSRs to one > > > distro's key makes it quite annoying to run another distro's intel_sgx > > > driver, but there is no effect on the actual security of the system. > > > > > I agree that for systems that firmware-lock the msrs are annoying, but I > > would > > think that
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > wrote: > > > > >> > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > >> user > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > >> enclave > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > >> Linux > > > > >> has full control of the enclave launch process. > > > > >> > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > >> implemented by using the user space helper framework. The IPC > > > > >> between > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > >> > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > >> points > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public > > > > >> key > > > > >> pair. The default location is: > > > > >> > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > >> > > > > >> If the default key does not exist kbuild will generate a random key > > > > >> and > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > > > >> the passphrase for the LE public key. > > > > > > > > > > It seems to me that it might be more useful to just commit a key pair > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > gained by keeping the private key private, so why not make > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > Having thought about this some more, I think that you should > > > > completely remove support for specifying a key. Provide a fixed key > > > > pair, hard code the cache, and call it a day. If you make the key > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > give some illusion of security and it'll slow down operations in a VM > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > support a locked MSR that just happens to have the right value stays > > > > in the kernel, then we'll risk having vendors actually ship one > > > > distro's public key hash, and that will seriously suck. > > > > > > > If you hard code the key pair however, doesn't that imply that anyone can > > > sign a > > > user space binary as a launch enclave, and potentially gain control of > > > the token > > > granting process? > > > > Yes and no. > > > > First of all, the kernel driver shouldn't be allowing user code to > > launch a launch enclave regardless of signature. I haven't gotten far > > enough in reviewing the code to see whether that's the case, but if > > it's not, it should be fixed before it's merged. > > > Ok, I agree with you here. > > > But keep in mind that control of the token granting process is not the > > same thing as control over the right to launch an enclave. On systems > > without the LE hash MSRs, Intel controls the token granting process > > and, barring some attack, an enclave that isn't blessed by Intel can't > > be launched. Support for that model will not be merged into upstream > > Linux. But on systems that have the LE hash MSRs and leave them > > unlocked, there is effectively no hardware-enforced launch control. > > Instead we have good old kernel policy. If a user wants to launch an > > enclave, they need to get the kernel to launch the enclave, and the > > kernel needs to apply its policy. The patch here (the in-kernel > > launch enclave) has a wide-open policy. > > > > Right, also agree here. Systems without Flexible Launch Control are a > non-starter, we're only considering FLC systems here > > > So, as a practical matter, if every distro has their own LE key and > > keeps it totally safe, then a system that locks the MSRs to one > > distro's key makes it quite annoying to run another distro's intel_sgx > > driver, but there is no effect on the actual security of the system. > > > I agree that for systems that firmware-lock the msrs are annoying, but I would > think that IHV's would want to keep those msrs unlocked specifically to allow > a > wide range of distributions to use this feature. > > As for benefits to security, I think there are some. Namely, by leaving the > MSRS unlocked, A distribution can, rather than providing their own > distirbution > key, pass
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote: > > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > > wrote: > > > > >> > > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for > > > > >> user > > > > >> enclaves. A launch token is used by EINIT to check whether the > > > > >> enclave > > > > >> is authorized to launch or not. By having its own launch enclave, > > > > >> Linux > > > > >> has full control of the enclave launch process. > > > > >> > > > > >> LE is wrapped into a user space proxy program that reads enclave > > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > > >> implemented by using the user space helper framework. The IPC > > > > >> between > > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > > >> > > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > > >> points > > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public > > > > >> key > > > > >> pair. The default location is: > > > > >> > > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > > >> > > > > >> If the default key does not exist kbuild will generate a random key > > > > >> and > > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > > > >> the passphrase for the LE public key. > > > > > > > > > > It seems to me that it might be more useful to just commit a key pair > > > > > into the kernel. As far as I know, there is no security whatsoever > > > > > gained by keeping the private key private, so why not make > > > > > reproducible builds easier by simply fixing the key? > > > > > > > > Having thought about this some more, I think that you should > > > > completely remove support for specifying a key. Provide a fixed key > > > > pair, hard code the cache, and call it a day. If you make the key > > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > > give some illusion of security and it'll slow down operations in a VM > > > > guest due to swapping out the values of the MSRs. And, if the code to > > > > support a locked MSR that just happens to have the right value stays > > > > in the kernel, then we'll risk having vendors actually ship one > > > > distro's public key hash, and that will seriously suck. > > > > > > > If you hard code the key pair however, doesn't that imply that anyone can > > > sign a > > > user space binary as a launch enclave, and potentially gain control of > > > the token > > > granting process? > > > > Yes and no. > > > > First of all, the kernel driver shouldn't be allowing user code to > > launch a launch enclave regardless of signature. I haven't gotten far > > enough in reviewing the code to see whether that's the case, but if > > it's not, it should be fixed before it's merged. > > > Ok, I agree with you here. > > > But keep in mind that control of the token granting process is not the > > same thing as control over the right to launch an enclave. On systems > > without the LE hash MSRs, Intel controls the token granting process > > and, barring some attack, an enclave that isn't blessed by Intel can't > > be launched. Support for that model will not be merged into upstream > > Linux. But on systems that have the LE hash MSRs and leave them > > unlocked, there is effectively no hardware-enforced launch control. > > Instead we have good old kernel policy. If a user wants to launch an > > enclave, they need to get the kernel to launch the enclave, and the > > kernel needs to apply its policy. The patch here (the in-kernel > > launch enclave) has a wide-open policy. > > > > Right, also agree here. Systems without Flexible Launch Control are a > non-starter, we're only considering FLC systems here > > > So, as a practical matter, if every distro has their own LE key and > > keeps it totally safe, then a system that locks the MSRs to one > > distro's key makes it quite annoying to run another distro's intel_sgx > > driver, but there is no effect on the actual security of the system. > > > I agree that for systems that firmware-lock the msrs are annoying, but I would > think that IHV's would want to keep those msrs unlocked specifically to allow > a > wide range of distributions to use this feature. > > As for benefits to security, I think there are some. Namely, by leaving the > MSRS unlocked, A distribution can, rather than providing their own > distirbution > key, pass
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > wrote: > > > >> > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > > > >> enclaves. A launch token is used by EINIT to check whether the enclave > > > >> is authorized to launch or not. By having its own launch enclave, Linux > > > >> has full control of the enclave launch process. > > > >> > > > >> LE is wrapped into a user space proxy program that reads enclave > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > >> implemented by using the user space helper framework. The IPC between > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > >> > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > >> points > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public > > > >> key > > > >> pair. The default location is: > > > >> > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > >> > > > >> If the default key does not exist kbuild will generate a random key and > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > > >> the passphrase for the LE public key. > > > > > > > > It seems to me that it might be more useful to just commit a key pair > > > > into the kernel. As far as I know, there is no security whatsoever > > > > gained by keeping the private key private, so why not make > > > > reproducible builds easier by simply fixing the key? > > > > > > Having thought about this some more, I think that you should > > > completely remove support for specifying a key. Provide a fixed key > > > pair, hard code the cache, and call it a day. If you make the key > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > give some illusion of security and it'll slow down operations in a VM > > > guest due to swapping out the values of the MSRs. And, if the code to > > > support a locked MSR that just happens to have the right value stays > > > in the kernel, then we'll risk having vendors actually ship one > > > distro's public key hash, and that will seriously suck. > > > > > If you hard code the key pair however, doesn't that imply that anyone can > > sign a > > user space binary as a launch enclave, and potentially gain control of the > > token > > granting process? > > Yes and no. > > First of all, the kernel driver shouldn't be allowing user code to > launch a launch enclave regardless of signature. I haven't gotten far > enough in reviewing the code to see whether that's the case, but if > it's not, it should be fixed before it's merged. > Ok, I agree with you here. > But keep in mind that control of the token granting process is not the > same thing as control over the right to launch an enclave. On systems > without the LE hash MSRs, Intel controls the token granting process > and, barring some attack, an enclave that isn't blessed by Intel can't > be launched. Support for that model will not be merged into upstream > Linux. But on systems that have the LE hash MSRs and leave them > unlocked, there is effectively no hardware-enforced launch control. > Instead we have good old kernel policy. If a user wants to launch an > enclave, they need to get the kernel to launch the enclave, and the > kernel needs to apply its policy. The patch here (the in-kernel > launch enclave) has a wide-open policy. > Right, also agree here. Systems without Flexible Launch Control are a non-starter, we're only considering FLC systems here > So, as a practical matter, if every distro has their own LE key and > keeps it totally safe, then a system that locks the MSRs to one > distro's key makes it quite annoying to run another distro's intel_sgx > driver, but there is no effect on the actual security of the system. > I agree that for systems that firmware-lock the msrs are annoying, but I would think that IHV's would want to keep those msrs unlocked specifically to allow a wide range of distributions to use this feature. As for benefits to security, I think there are some. Namely, by leaving the MSRS unlocked, A distribution can, rather than providing their own distirbution key, pass the root of trust on to the end user. I can easily envision a downstream customer that wants to use SGX, and do so in such a way that they are assured that their OS vendor doesn't have the ability to run an LE on their system (at least not without the visual cue of specifying a different key
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote: > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > > wrote: > > > >> > > > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > > > >> enclaves. A launch token is used by EINIT to check whether the enclave > > > >> is authorized to launch or not. By having its own launch enclave, Linux > > > >> has full control of the enclave launch process. > > > >> > > > >> LE is wrapped into a user space proxy program that reads enclave > > > >> signatures outputs launch tokens. The kernel-side glue code is > > > >> implemented by using the user space helper framework. The IPC between > > > >> the LE proxy program and kernel is handled with an anonymous inode. > > > >> > > > >> The commit also adds enclave signing tool that is used by kbuild to > > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY > > > >> points > > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public > > > >> key > > > >> pair. The default location is: > > > >> > > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > > >> > > > >> If the default key does not exist kbuild will generate a random key and > > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > > >> the passphrase for the LE public key. > > > > > > > > It seems to me that it might be more useful to just commit a key pair > > > > into the kernel. As far as I know, there is no security whatsoever > > > > gained by keeping the private key private, so why not make > > > > reproducible builds easier by simply fixing the key? > > > > > > Having thought about this some more, I think that you should > > > completely remove support for specifying a key. Provide a fixed key > > > pair, hard code the cache, and call it a day. If you make the key > > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > > and set up their own key pair for no gain whatsoever. Instead, it'll > > > give some illusion of security and it'll slow down operations in a VM > > > guest due to swapping out the values of the MSRs. And, if the code to > > > support a locked MSR that just happens to have the right value stays > > > in the kernel, then we'll risk having vendors actually ship one > > > distro's public key hash, and that will seriously suck. > > > > > If you hard code the key pair however, doesn't that imply that anyone can > > sign a > > user space binary as a launch enclave, and potentially gain control of the > > token > > granting process? > > Yes and no. > > First of all, the kernel driver shouldn't be allowing user code to > launch a launch enclave regardless of signature. I haven't gotten far > enough in reviewing the code to see whether that's the case, but if > it's not, it should be fixed before it's merged. > Ok, I agree with you here. > But keep in mind that control of the token granting process is not the > same thing as control over the right to launch an enclave. On systems > without the LE hash MSRs, Intel controls the token granting process > and, barring some attack, an enclave that isn't blessed by Intel can't > be launched. Support for that model will not be merged into upstream > Linux. But on systems that have the LE hash MSRs and leave them > unlocked, there is effectively no hardware-enforced launch control. > Instead we have good old kernel policy. If a user wants to launch an > enclave, they need to get the kernel to launch the enclave, and the > kernel needs to apply its policy. The patch here (the in-kernel > launch enclave) has a wide-open policy. > Right, also agree here. Systems without Flexible Launch Control are a non-starter, we're only considering FLC systems here > So, as a practical matter, if every distro has their own LE key and > keeps it totally safe, then a system that locks the MSRs to one > distro's key makes it quite annoying to run another distro's intel_sgx > driver, but there is no effect on the actual security of the system. > I agree that for systems that firmware-lock the msrs are annoying, but I would think that IHV's would want to keep those msrs unlocked specifically to allow a wide range of distributions to use this feature. As for benefits to security, I think there are some. Namely, by leaving the MSRS unlocked, A distribution can, rather than providing their own distirbution key, pass the root of trust on to the end user. I can easily envision a downstream customer that wants to use SGX, and do so in such a way that they are assured that their OS vendor doesn't have the ability to run an LE on their system (at least not without the visual cue of specifying a different key
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > wrote: > > >> > > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > > >> enclaves. A launch token is used by EINIT to check whether the enclave > > >> is authorized to launch or not. By having its own launch enclave, Linux > > >> has full control of the enclave launch process. > > >> > > >> LE is wrapped into a user space proxy program that reads enclave > > >> signatures outputs launch tokens. The kernel-side glue code is > > >> implemented by using the user space helper framework. The IPC between > > >> the LE proxy program and kernel is handled with an anonymous inode. > > >> > > >> The commit also adds enclave signing tool that is used by kbuild to > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > > >> pair. The default location is: > > >> > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > >> > > >> If the default key does not exist kbuild will generate a random key and > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > >> the passphrase for the LE public key. > > > > > > It seems to me that it might be more useful to just commit a key pair > > > into the kernel. As far as I know, there is no security whatsoever > > > gained by keeping the private key private, so why not make > > > reproducible builds easier by simply fixing the key? > > > > Having thought about this some more, I think that you should > > completely remove support for specifying a key. Provide a fixed key > > pair, hard code the cache, and call it a day. If you make the key > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > and set up their own key pair for no gain whatsoever. Instead, it'll > > give some illusion of security and it'll slow down operations in a VM > > guest due to swapping out the values of the MSRs. And, if the code to > > support a locked MSR that just happens to have the right value stays > > in the kernel, then we'll risk having vendors actually ship one > > distro's public key hash, and that will seriously suck. > > > If you hard code the key pair however, doesn't that imply that anyone can > sign a > user space binary as a launch enclave, and potentially gain control of the > token > granting process? Yes and no. First of all, the kernel driver shouldn't be allowing user code to launch a launch enclave regardless of signature. I haven't gotten far enough in reviewing the code to see whether that's the case, but if it's not, it should be fixed before it's merged. But keep in mind that control of the token granting process is not the same thing as control over the right to launch an enclave. On systems without the LE hash MSRs, Intel controls the token granting process and, barring some attack, an enclave that isn't blessed by Intel can't be launched. Support for that model will not be merged into upstream Linux. But on systems that have the LE hash MSRs and leave them unlocked, there is effectively no hardware-enforced launch control. Instead we have good old kernel policy. If a user wants to launch an enclave, they need to get the kernel to launch the enclave, and the kernel needs to apply its policy. The patch here (the in-kernel launch enclave) has a wide-open policy. So, as a practical matter, if every distro has their own LE key and keeps it totally safe, then a system that locks the MSRs to one distro's key makes it quite annoying to run another distro's intel_sgx driver, but there is no effect on the actual security of the system. > It was my understanding that the value of the key pair was > that the end user was guaranteed autonomy and security over which processes > could start enclaves. By publishing a fixed key pair, it seems to remove that > ability. If someone comes up with an actual machine that grants the actual end user (where the end user is the person who bought the thing, not the OEM) control over the MSRs, *and* the actual end user wants to limit what enclaves can be launched even if the kernel is compromised, *and* there is some actual argument for why this is useful (as opposed to some compliance checkbox), then Linux could reasonably consider adding support for this use case. But that would be a separate patch. > > What would be nicer (I think) would be the abilty to specify both the public > and > the private key at run time. the use case here is not one in which a vendor > or > os distribution ships a key pair, but one in which a downstream user doesn't > want a vendor/os distribution to have any cryptographic information installed > on > their
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > wrote: > > >> > > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > > >> enclaves. A launch token is used by EINIT to check whether the enclave > > >> is authorized to launch or not. By having its own launch enclave, Linux > > >> has full control of the enclave launch process. > > >> > > >> LE is wrapped into a user space proxy program that reads enclave > > >> signatures outputs launch tokens. The kernel-side glue code is > > >> implemented by using the user space helper framework. The IPC between > > >> the LE proxy program and kernel is handled with an anonymous inode. > > >> > > >> The commit also adds enclave signing tool that is used by kbuild to > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > > >> pair. The default location is: > > >> > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > >> > > >> If the default key does not exist kbuild will generate a random key and > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > >> the passphrase for the LE public key. > > > > > > It seems to me that it might be more useful to just commit a key pair > > > into the kernel. As far as I know, there is no security whatsoever > > > gained by keeping the private key private, so why not make > > > reproducible builds easier by simply fixing the key? > > > > Having thought about this some more, I think that you should > > completely remove support for specifying a key. Provide a fixed key > > pair, hard code the cache, and call it a day. If you make the key > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > and set up their own key pair for no gain whatsoever. Instead, it'll > > give some illusion of security and it'll slow down operations in a VM > > guest due to swapping out the values of the MSRs. And, if the code to > > support a locked MSR that just happens to have the right value stays > > in the kernel, then we'll risk having vendors actually ship one > > distro's public key hash, and that will seriously suck. > > > If you hard code the key pair however, doesn't that imply that anyone can > sign a > user space binary as a launch enclave, and potentially gain control of the > token > granting process? Yes and no. First of all, the kernel driver shouldn't be allowing user code to launch a launch enclave regardless of signature. I haven't gotten far enough in reviewing the code to see whether that's the case, but if it's not, it should be fixed before it's merged. But keep in mind that control of the token granting process is not the same thing as control over the right to launch an enclave. On systems without the LE hash MSRs, Intel controls the token granting process and, barring some attack, an enclave that isn't blessed by Intel can't be launched. Support for that model will not be merged into upstream Linux. But on systems that have the LE hash MSRs and leave them unlocked, there is effectively no hardware-enforced launch control. Instead we have good old kernel policy. If a user wants to launch an enclave, they need to get the kernel to launch the enclave, and the kernel needs to apply its policy. The patch here (the in-kernel launch enclave) has a wide-open policy. So, as a practical matter, if every distro has their own LE key and keeps it totally safe, then a system that locks the MSRs to one distro's key makes it quite annoying to run another distro's intel_sgx driver, but there is no effect on the actual security of the system. > It was my understanding that the value of the key pair was > that the end user was guaranteed autonomy and security over which processes > could start enclaves. By publishing a fixed key pair, it seems to remove that > ability. If someone comes up with an actual machine that grants the actual end user (where the end user is the person who bought the thing, not the OEM) control over the MSRs, *and* the actual end user wants to limit what enclaves can be launched even if the kernel is compromised, *and* there is some actual argument for why this is useful (as opposed to some compliance checkbox), then Linux could reasonably consider adding support for this use case. But that would be a separate patch. > > What would be nicer (I think) would be the abilty to specify both the public > and > the private key at run time. the use case here is not one in which a vendor > or > os distribution ships a key pair, but one in which a downstream user doesn't > want a vendor/os distribution to have any cryptographic information installed > on > their
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > wrote: > >> > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > >> enclaves. A launch token is used by EINIT to check whether the enclave > >> is authorized to launch or not. By having its own launch enclave, Linux > >> has full control of the enclave launch process. > >> > >> LE is wrapped into a user space proxy program that reads enclave > >> signatures outputs launch tokens. The kernel-side glue code is > >> implemented by using the user space helper framework. The IPC between > >> the LE proxy program and kernel is handled with an anonymous inode. > >> > >> The commit also adds enclave signing tool that is used by kbuild to > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > >> pair. The default location is: > >> > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > >> > >> If the default key does not exist kbuild will generate a random key and > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > >> the passphrase for the LE public key. > > > > It seems to me that it might be more useful to just commit a key pair > > into the kernel. As far as I know, there is no security whatsoever > > gained by keeping the private key private, so why not make > > reproducible builds easier by simply fixing the key? > > Having thought about this some more, I think that you should > completely remove support for specifying a key. Provide a fixed key > pair, hard code the cache, and call it a day. If you make the key > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > and set up their own key pair for no gain whatsoever. Instead, it'll > give some illusion of security and it'll slow down operations in a VM > guest due to swapping out the values of the MSRs. And, if the code to > support a locked MSR that just happens to have the right value stays > in the kernel, then we'll risk having vendors actually ship one > distro's public key hash, and that will seriously suck. > If you hard code the key pair however, doesn't that imply that anyone can sign a user space binary as a launch enclave, and potentially gain control of the token granting process? It was my understanding that the value of the key pair was that the end user was guaranteed autonomy and security over which processes could start enclaves. By publishing a fixed key pair, it seems to remove that ability. What would be nicer (I think) would be the abilty to specify both the public and the private key at run time. the use case here is not one in which a vendor or os distribution ships a key pair, but one in which a downstream user doesn't want a vendor/os distribution to have any cryptographic information installed on their system Neil
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > wrote: > >> > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > >> enclaves. A launch token is used by EINIT to check whether the enclave > >> is authorized to launch or not. By having its own launch enclave, Linux > >> has full control of the enclave launch process. > >> > >> LE is wrapped into a user space proxy program that reads enclave > >> signatures outputs launch tokens. The kernel-side glue code is > >> implemented by using the user space helper framework. The IPC between > >> the LE proxy program and kernel is handled with an anonymous inode. > >> > >> The commit also adds enclave signing tool that is used by kbuild to > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > >> pair. The default location is: > >> > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > >> > >> If the default key does not exist kbuild will generate a random key and > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > >> the passphrase for the LE public key. > > > > It seems to me that it might be more useful to just commit a key pair > > into the kernel. As far as I know, there is no security whatsoever > > gained by keeping the private key private, so why not make > > reproducible builds easier by simply fixing the key? > > Having thought about this some more, I think that you should > completely remove support for specifying a key. Provide a fixed key > pair, hard code the cache, and call it a day. If you make the key > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > and set up their own key pair for no gain whatsoever. Instead, it'll > give some illusion of security and it'll slow down operations in a VM > guest due to swapping out the values of the MSRs. And, if the code to > support a locked MSR that just happens to have the right value stays > in the kernel, then we'll risk having vendors actually ship one > distro's public key hash, and that will seriously suck. > If you hard code the key pair however, doesn't that imply that anyone can sign a user space binary as a launch enclave, and potentially gain control of the token granting process? It was my understanding that the value of the key pair was that the end user was guaranteed autonomy and security over which processes could start enclaves. By publishing a fixed key pair, it seems to remove that ability. What would be nicer (I think) would be the abilty to specify both the public and the private key at run time. the use case here is not one in which a vendor or os distribution ships a key pair, but one in which a downstream user doesn't want a vendor/os distribution to have any cryptographic information installed on their system Neil
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
> On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > wrote: >> >> The Launch Enclave (LE) generates cryptographic launch tokens for user >> enclaves. A launch token is used by EINIT to check whether the enclave >> is authorized to launch or not. By having its own launch enclave, Linux >> has full control of the enclave launch process. >> >> LE is wrapped into a user space proxy program that reads enclave >> signatures outputs launch tokens. The kernel-side glue code is >> implemented by using the user space helper framework. The IPC between >> the LE proxy program and kernel is handled with an anonymous inode. >> >> The commit also adds enclave signing tool that is used by kbuild to >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key >> pair. The default location is: >> >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem >> >> If the default key does not exist kbuild will generate a random key and >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify >> the passphrase for the LE public key. > > It seems to me that it might be more useful to just commit a key pair > into the kernel. As far as I know, there is no security whatsoever > gained by keeping the private key private, so why not make > reproducible builds easier by simply fixing the key? Having thought about this some more, I think that you should completely remove support for specifying a key. Provide a fixed key pair, hard code the cache, and call it a day. If you make the key configurable, every vendor that has any vendor keys (Debian, Ubuntu, Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option and set up their own key pair for no gain whatsoever. Instead, it'll give some illusion of security and it'll slow down operations in a VM guest due to swapping out the values of the MSRs. And, if the code to support a locked MSR that just happens to have the right value stays in the kernel, then we'll risk having vendors actually ship one distro's public key hash, and that will seriously suck. I'm going to try to get this code working tomorrow. I'll keep you posted on how that goes. Can you point me to the userspace bits (i.e. something buildable that will run on a kernel with your patches applied)? > > Also, this email is so long that gmail won't let me quote the relevant > code, but: what is the intended use case for supporting the mode where > the MSRs are locked but happen to contain the right value? I could > see the case for bundling a key with the kernel and literally > hard-coding the acceptable MSR values (as in literal values in the > code, not even autogenerated hashes). The only use case I've thought > of for the code as it stands is that $VENDOR could publish their LE > public key and some daft firmware vendor could get it into their head > that it would be a good idea to lock the MSRs to that value. This > would add no security at all, but it would add a considerable about of > annoyance and loss of value, so I still tend to think that we > shouldn't support it.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
> On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > wrote: >> >> The Launch Enclave (LE) generates cryptographic launch tokens for user >> enclaves. A launch token is used by EINIT to check whether the enclave >> is authorized to launch or not. By having its own launch enclave, Linux >> has full control of the enclave launch process. >> >> LE is wrapped into a user space proxy program that reads enclave >> signatures outputs launch tokens. The kernel-side glue code is >> implemented by using the user space helper framework. The IPC between >> the LE proxy program and kernel is handled with an anonymous inode. >> >> The commit also adds enclave signing tool that is used by kbuild to >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key >> pair. The default location is: >> >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem >> >> If the default key does not exist kbuild will generate a random key and >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify >> the passphrase for the LE public key. > > It seems to me that it might be more useful to just commit a key pair > into the kernel. As far as I know, there is no security whatsoever > gained by keeping the private key private, so why not make > reproducible builds easier by simply fixing the key? Having thought about this some more, I think that you should completely remove support for specifying a key. Provide a fixed key pair, hard code the cache, and call it a day. If you make the key configurable, every vendor that has any vendor keys (Debian, Ubuntu, Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option and set up their own key pair for no gain whatsoever. Instead, it'll give some illusion of security and it'll slow down operations in a VM guest due to swapping out the values of the MSRs. And, if the code to support a locked MSR that just happens to have the right value stays in the kernel, then we'll risk having vendors actually ship one distro's public key hash, and that will seriously suck. I'm going to try to get this code working tomorrow. I'll keep you posted on how that goes. Can you point me to the userspace bits (i.e. something buildable that will run on a kernel with your patches applied)? > > Also, this email is so long that gmail won't let me quote the relevant > code, but: what is the intended use case for supporting the mode where > the MSRs are locked but happen to contain the right value? I could > see the case for bundling a key with the kernel and literally > hard-coding the acceptable MSR values (as in literal values in the > code, not even autogenerated hashes). The only use case I've thought > of for the code as it stands is that $VENDOR could publish their LE > public key and some daft firmware vendor could get it into their head > that it would be a good idea to lock the MSRs to that value. This > would add no security at all, but it would add a considerable about of > annoyance and loss of value, so I still tend to think that we > shouldn't support it.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen wrote: > > The Launch Enclave (LE) generates cryptographic launch tokens for user > enclaves. A launch token is used by EINIT to check whether the enclave > is authorized to launch or not. By having its own launch enclave, Linux > has full control of the enclave launch process. > > LE is wrapped into a user space proxy program that reads enclave > signatures outputs launch tokens. The kernel-side glue code is > implemented by using the user space helper framework. The IPC between > the LE proxy program and kernel is handled with an anonymous inode. > > The commit also adds enclave signing tool that is used by kbuild to > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > pair. The default location is: > > drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > If the default key does not exist kbuild will generate a random key and > place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > the passphrase for the LE public key. It seems to me that it might be more useful to just commit a key pair into the kernel. As far as I know, there is no security whatsoever gained by keeping the private key private, so why not make reproducible builds easier by simply fixing the key? Also, this email is so long that gmail won't let me quote the relevant code, but: what is the intended use case for supporting the mode where the MSRs are locked but happen to contain the right value? I could see the case for bundling a key with the kernel and literally hard-coding the acceptable MSR values (as in literal values in the code, not even autogenerated hashes). The only use case I've thought of for the code as it stands is that $VENDOR could publish their LE public key and some daft firmware vendor could get it into their head that it would be a good idea to lock the MSRs to that value. This would add no security at all, but it would add a considerable about of annoyance and loss of value, so I still tend to think that we shouldn't support it.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen wrote: > > The Launch Enclave (LE) generates cryptographic launch tokens for user > enclaves. A launch token is used by EINIT to check whether the enclave > is authorized to launch or not. By having its own launch enclave, Linux > has full control of the enclave launch process. > > LE is wrapped into a user space proxy program that reads enclave > signatures outputs launch tokens. The kernel-side glue code is > implemented by using the user space helper framework. The IPC between > the LE proxy program and kernel is handled with an anonymous inode. > > The commit also adds enclave signing tool that is used by kbuild to > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > pair. The default location is: > > drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > If the default key does not exist kbuild will generate a random key and > place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > the passphrase for the LE public key. It seems to me that it might be more useful to just commit a key pair into the kernel. As far as I know, there is no security whatsoever gained by keeping the private key private, so why not make reproducible builds easier by simply fixing the key? Also, this email is so long that gmail won't let me quote the relevant code, but: what is the intended use case for supporting the mode where the MSRs are locked but happen to contain the right value? I could see the case for bundling a key with the kernel and literally hard-coding the acceptable MSR values (as in literal values in the code, not even autogenerated hashes). The only use case I've thought of for the code as it stands is that $VENDOR could publish their LE public key and some daft firmware vendor could get it into their head that it would be a good idea to lock the MSRs to that value. This would add no security at all, but it would add a considerable about of annoyance and loss of value, so I still tend to think that we shouldn't support it.
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen wrote: > > The Launch Enclave (LE) generates cryptographic launch tokens for user > enclaves. A launch token is used by EINIT to check whether the enclave > is authorized to launch or not. By having its own launch enclave, Linux > has full control of the enclave launch process. > > LE is wrapped into a user space proxy program that reads enclave > signatures outputs launch tokens. The kernel-side glue code is > implemented by using the user space helper framework. The IPC between > the LE proxy program and kernel is handled with an anonymous inode. > > The commit also adds enclave signing tool that is used by kbuild to > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > pair. The default location is: It might be nice to use the infrastructure that Alexei added for bpfilter (the umh_blob stuff) here, which is slated for merging in this merge window. --Andy
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen wrote: > > The Launch Enclave (LE) generates cryptographic launch tokens for user > enclaves. A launch token is used by EINIT to check whether the enclave > is authorized to launch or not. By having its own launch enclave, Linux > has full control of the enclave launch process. > > LE is wrapped into a user space proxy program that reads enclave > signatures outputs launch tokens. The kernel-side glue code is > implemented by using the user space helper framework. The IPC between > the LE proxy program and kernel is handled with an anonymous inode. > > The commit also adds enclave signing tool that is used by kbuild to > measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > to a PEM-file for the 3072-bit RSA key that is used as the LE public key > pair. The default location is: It might be nice to use the infrastructure that Alexei added for bpfilter (the umh_blob stuff) here, which is slated for merging in this merge window. --Andy
