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

[Borislav Petkov]

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.

> Given the number of steps BIOS needs to take to enable SGX, that'd be one
> "inventive" BIOS. :-)

Oh, you have no idea the amount of BIOS shit I've experienced.

> 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.

... 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.

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.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette