linux-kernel - Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE

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: <CALCETrWxA6AgU8zg=npS=4NaA1_Pu9UwScEnr_Gk0wF-BOmqqQ@mail.gmail.com>
Date:   Sat, 24 Oct 2020 08:47:28 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Jarkko Sakkinen <kernel.org@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, linux-sgx@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Jethro Beekman <jethro@...tanix.com>,
        Darren Kenny <darren.kenny@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asapek@...gle.com, Borislav Petkov <bp@...en8.de>,
        "Xing, Cedric" <cedric.xing@...el.com>, chenalexchen@...gle.com,
        Conrad Parker <conradparker@...gle.com>, cyhanish@...gle.com,
        "Huang, Haitao" <haitao.huang@...el.com>,
        "Huang, Kai" <kai.huang@...el.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Keith Moyer <kmoy@...gle.com>,
        Christian Ludloff <ludloff@...gle.com>,
        Neil Horman <nhorman@...hat.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Patrick Uiterwijk <puiterwijk@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>, yaozhangx@...gle.com,
        Mikko Ylinen <mikko.ylinen@...el.com>
Subject: Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION

On Sat, Oct 24, 2020 at 4:34 AM Jarkko Sakkinen <kernel.org@...nel.org> wrote:
>
> On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote:
> > On 10/23/20 3:17 AM, Jarkko Sakkinen wrote:
> > > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote:
> > >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote:
> > >>> + * Failure to explicitly request access to a restricted attribute will cause
> > >>> + * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
> > >>> + * is access to the PROVISION_KEY.
> > >> Could we also justify why access is restricted, please?  Maybe:
> > >>
> > >>    Access is restricted because PROVISION_KEY is burned uniquely
> > >>    into each each processor, making it a perfect unique identifier
> > >>    with privacy and fingerprinting implications.
> > >>
> > >> Are there any other reasons for doing it this way?
> > > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and
> > > PROVISION_SEALING_KEY also have random salt added, i.e. they change
> > > every boot cycle.
> > >
> > > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume
> > > 3D :-)
> >
> > Does that mean there are no privacy implications from access to the
> > provisioning keys?  If that's true, why do we need a separate permission
> > framework for creating provisioning enclaves?
>
> As I've understood it, the key material for those keys is not even
> required in the current SGX architecture, it was used in the legacy EPID
> scheme, but the attribute itself is useful.
>
> Let's assume that we have some sort of quoting enclave Q, which guards a
> public key pair, which signs quotes of other enclaves. Let's assume we
> have an attestation server A, which will enable some capabilities [*],
> if it receives a quote signed with that public key pair.
>
> 1. E gets the report key with EGETKEY.
> 2. E constructs REPORTDATA (37.16) and TARGETINFO (37.17) structures.
>    The former describes the enclaves contents and attributes and latter
>    the target, i.e. Q in this artitificial example.
> 3. E calls EREPORT to generate a structure called REPORT MAC'd with the
>    *targets* report key. It knows, which key to usue from REPORTDATA.
> 4. The runtime will then pass this to Q.
> 5. Q will check if ATTRIBUTE.PROVISION_KEY is set. If it is, Q will
>    know that the enclave is allowed to get attested. Then it will
>    sign the report with the guarded public key pair and send it to
>    the attestation server.

I think you have this a little bit off.  AIUI E won't have
ATTRIBUTE.PROVISION_KEY set -- Q will.  Q uses the provisioning key to
convince an Intel server that it's running on a genuine Intel CPU, and
the Intel server will return a signed certificate that Q can chain off
of to generate attestations for E.

Dave, I would rephrase what you're saying a bit.  The PROVISION_KEY
attribute allows enclaves to access keys that are unique to a
processor and unchangeable.  Unlike other SGX keys, these keys are not
affected by OWNER_EPOCH changes and therefore cannot be reset.

--Andy