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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 25 Sep 2019 11:18:14 -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 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@intel.com
> 
> ... 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.