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

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Wed, Sep 25, 2019 at 08:31:36PM +0200, Borislav Petkov wrote:
> On Wed, Sep 25, 2019 at 10:18:24AM -0700, Sean Christopherson wrote:
> > Realistically, there will likely be a non-trivial number of systems with
> > SGX_LE_WR=0 but SGX enabled.
> 
> Well no. We won't support those. I remember very vividly at Tech Days a
> couple of years ago where we said we won't support locked down systems.

Yep, that's our intent as well.

> > It's inevitable that some systems will lock down the LE hash MSRs, either
> > intentionally or due to lack of support for SGX_LE_WR.  The latter is
> > probably going to be more common than OEMs intentionally locking the MSRs,
> > because some Intel reference BIOSes simply don't support SGX_LE_WR, e.g. I
> > have a Coffee Lake SDP that has hardware support for SGX_LC, but the BIOS
> > doesn't provide any way to set SGX_LE_WR or leave FEATURE_CONTROL unlocked.
> 
> We won't support those too. Nothing changes since a couple of years ago.
> We won't support locked down systems and unfinished BIOS systems.

Yep.

> ... reading your other mail about KVM...
> 
> I guess KVM could be an exception here if people wanna run different
> OSes in the guest. IMHO.
>
> For that, though, we should still clear all SGX feature bits in the
> host, I'd say, and let the kvm module rediscover everything itself
> through CPUID directly and not using *cpu_has*
> 
> Why, you ask? Because otherwise users will start asking why do they have
> "sgx" in /proc/cpuinfo but they can't run their own enclaves.

That makes sense.  I was thinking it'd be helpful to leave the bits set,
e.g. for users to differentiate between "I don't have SGX" and "I can't
use SGX because SGX_LC is disabled".  But I'm probably being slightly
optomistic...

> But maybe someone has a better idea.
> 
> In any case, I think it would be bad idea to show only a subset of
> features in /proc/cpuinfo of a locked-down system and have to explain it
> to users why they can't do own enclaves.
> 
> But again, someone might have a better idea.

I'm 99% certain this won't even require a change to the proposed KVM
patches, as KVM mostly pulls SGX support directly from CPUID.  The only
thing it checks via cpu_has() is SGX_LC to query whether or not the MSRs
are fully writable.

Keeping the SGX feature bits set was more about reflecting hardware
capabilities than it was a functional requirement.