lkml.org 
[lkml]   [2019]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v22 02/24] x86/cpufeatures: x86/msr: Intel SGX Launch Control hardware bits
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.

\
 
 \ /
  Last update: 2019-09-25 21:08    [W:0.096 / U:5.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site