Re: [PATCH v22 02/24] x86/cpufeatures: x86/msr: Intel SGX Launch Control hardware bits

[Sean Christopherson]

On Wed, Sep 25, 2019 at 07:28:15PM +0200, Borislav Petkov wrote:
> On Wed, Sep 25, 2019 at 09:49:32AM -0700, Sean Christopherson wrote:
> > Correct, only X86_FEATURE_SGX_LC is cleared.  The idea is to have SGX_LC
> > reflect whether or not flexible launch control is fully enabled, no more
> > no less.
> 
> So we do not disable SGX when the MSRs are read-only - we disable only
> launch control.
> 
> > Functionally, this doesn't impact support for native enclaves as the
> > driver will refuse to load if SGX_LC=0.
> 
> So why aren't we clearing all feature bits then? What's the purpose for
> leaving them set if we're not going to support hardcoded OEM vendor hash
> in the MSRs anyway?

To allow KVM to expose SGX to guests even if the MSRs are locked down.

> > Looking forward, this *will* affect KVM.  As proposed, KVM would expose
> > SGX to a guest regardless of SGX_LC support.
> > 
> > https://lkml.kernel.org/r/20190727055214.9282-17-sean.j.christopherson@xxxxxxxxx
> 
> ... which would do what exactly? Guests can execute SGX only
> when signed by the Intel key, when LC is disabled?

Guest can only run launch enclaves that are signed by whatever key matches
the LE hash MSRs.  That could be an Intel key, e.g. if BIOS neglected to
set FEATURE_CONTROL.SGX_LE_WR=1, or some third party key if BIOS
deliberately rewrote the hash MSRs and cleared SGX_LE_WR.

A mainline Linux kernel in the guest would not allow running enclaves due
to the MSRs being locked, i.e. doing an end-around on the host kernel to
run enclaves on a locked system would require a custom Linux kernel or a
different OS entirely.