On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> 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
