linux-kernel - Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel

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: <CALCETrXos3b-VJxLCb1nwP1x2s5jiDmuQDWVahTVdXGxhqqsDw@mail.gmail.com>
Date:   Mon, 25 Jun 2018 08:45:31 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     npmccallum@...hat.com,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Jethro Beekman <jethro@...tanix.com>,
        Andrew Lutomirski <luto@...nel.org>, nhorman@...hat.com,
        X86 ML <x86@...nel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        intel-sgx-kernel-dev@...ts.01.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Darren Hart <dvhart@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>, andy@...radead.org,
        Peter Jones <pjones@...hat.com>
Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel
 launch enclave

On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen
<jarkko.sakkinen@...ux.intel.com> wrote:
>
> On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> > This implies that it should be possible to create MSR activation (and
> > an embedded launch enclave?) entirely as a UEFI module. The kernel
> > would still get to manage who has access to /dev/sgx and other
> > important non-cryptographic policy details. Users would still be able
> > to control the cryptographic policy details (via BIOS Secure Boot
> > configuration that exists today). Distributions could still control
> > cryptographic policy details via signing of the UEFI module with their
> > own Secure Boot key (or using something like shim). The UEFI module
> > (and possibly the external launch enclave) could be distributed via
> > linux-firmware.
> >
> > Andy/Neil, does this work for you?
>
> Nothing against having UEFI module for MSR activation step.
>
> And we would move the existing in-kernel LE to firmware so that it is
> avaible for locked-in-to-non-Intel-values case?
>

This is a hell of a lot of complexity.  To get it right we'd need an
actual formal spec of what firmware is supposed to do and how it
integrates with the kernel, and we'd need a reason why it's useful.

I'm personally rather strongly in favor of the vastly simpler model in
which we first merge SGX without LE support at all.  Instead we use
the approach where we just twiddle the MSRs to launch normal enclaves
without an init token at all, which is probably considerably faster
and will remove several thousand lines of code.  If and when a bona
fide use case for LE support shows up, we can work out the details and
merge it.

Right now, we're talking about a lot of design considerations, a lot
of interoperability considerations, and a lot of code to support a use
case that doesn't clearly exist.

--Andy