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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190925190825.GK31852@linux.intel.com>
Date:   Wed, 25 Sep 2019 12:08:26 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
        dave.hansen@...el.com, nhorman@...hat.com, npmccallum@...hat.com,
        serge.ayoun@...el.com, shay.katz-zamir@...el.com,
        haitao.huang@...el.com, andriy.shevchenko@...ux.intel.com,
        tglx@...utronix.de, kai.svahn@...el.com, josh@...htriplett.org,
        luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com,
        cedric.xing@...el.com, Kai Huang <kai.huang@...ux.intel.com>,
        Haim Cohen <haim.cohen@...el.com>
Subject: Re: [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.