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: <20190925183136.GH3891@zn.tnic>
Date:   Wed, 25 Sep 2019 20:31:36 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
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 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