Message-ID: <20181124201318.GB12149@wind.enjellic.com>
Date:   Sat, 24 Nov 2018 14:13:18 -0600
From:   "Dr. Greg" <greg@...ellic.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        linux-sgx@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        nhorman@...hat.com, npmccallum@...hat.com,
        "Ayoun, Serge" <serge.ayoun@...el.com>, shay.katz-zamir@...el.com,
        haitao.huang@...ux.intel.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Svahn, Kai" <kai.svahn@...el.com>, mark.shanahan@...el.com,
        Suresh Siddha <suresh.b.siddha@...el.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote:
> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote:
> > > At a high level, addressing these issues is straight forward.  First,
> > > the driver needs to support authorization equivalent to that which is
> > > implemented in the current Intel Launch Enclave, ie. control over the
> > > SGX_FLAGS_PROVISION_KEY attribute.
> > 
> > I agree, hence my email :)

> Started to scratch my head that is it really an issue that any
> enclave can provision in the end?
>
> Direct quote from your first response:
>
> "In particular, the ability to run enclaves with the provisioning
> bit set is somewhat sensitive, since it effectively allows access to
> a stable fingerprint of the system."
>
> As can be seen from the key derivation table this does not exactly
> hold so you should refine your original argument before we can
> consider any type of change.
>
> I just don't see what it is so wrong for any enclave to be able to
> tell that it really is an enclave.

This isn't about an enclave being able to tell that it is really an
enclave.  As I noted in my previous reply, access to the provisioning
bit allows an enclave author to create a perpetual hardware identifier
for a platform based on a signing key of their choosing, along with a
few other incidentals, all of which are completely under the control
of the enclave author.

The Intel SGX architects, at least originally, felt strongly enough
about this issue to use the Launch Enclave to implement
cryptographically secure policy control over access to the
SGX_FLAGS_PROVISION_KEY attribute.  See the 'if' clause that begins on
line 219 of psw/ae/le/launch_enclave.cpp in the current HEAD of the
Linux SGX SDK which is currently bf22963411.

Let me describe an entirely contrived example but one which is
representative of the threat.

I'm a web-site that wants to consistently and reliably track platforms
that visit a site.  Without cryptographically secure policy
enforcement in the SGX eco-system I push an enclave to the platform
which only computes the MRSIGNER specific derived provisioning key and
returns it to the web-site.

>From that point onward I will always be able to identify the platform,
as long as the enclave can be executed on the platform.  Unlike
cookies, there is nothing to delete since the aggressor enclave only
needs to exist long enough to be run and generate the derived
provisioning key, no trace of the fingerprinting remains thereafter.

If the proposed driver is to be a functional replacement for the
existing SGX eco-system it needs to offer privacy and platform
security guarantees at least comparable to what is available on a
non-FLC system.  That means at least some semblance of
cryptographically secure policy management on at least two fronts.

We can propose a general architecture that we believe satisfies these
needs without compromising the upstream integrity of the kernel with
respect to free and open systems.  A solution that could arguably
protect user's investment in current non-FLC hardware as well.

We would be happy to articulate the outline of that but I don't want
to waste anyone's time, including ours, if everyone's mind has been
made up as to what the driver should and should not do.

We are clearly capable of making the proposed driver do whatever we
want it to do.  Our concern is that Linux security architects that
choose to use this technology have the best tools available to them,
within the constraints of upstream sensibility, without whacking on
the kernel.

As it stands now the driver has both privacy and potential system
security issues which translate into useability and desirability
implications for SGX on Linux moving forward.

> /Jarkko

Have a good remainder of the weekend.

I need to get back to my MIG welder out in the shop.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"Attendants at a service station in Eunice, Louisiana, handed more than
 $100 to a naked man who claimed to have a gun in his pocket."
                                -- Unknown

Powered by blists - more mailing lists