linux-kernel - Re: x86/sgx: uapi change proposal

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: <20181220103400.GC26410@linux.intel.com>
Date:   Thu, 20 Dec 2018 12:34:00 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     Jethro Beekman <jethro@...tanix.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Josh Triplett <josh@...htriplett.org>,
        Haitao Huang <haitao.huang@...ux.intel.com>
Subject: Re: x86/sgx: uapi change proposal

On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> I believe it is a silent response to the issues we were prosecuting
> 4-5 weeks ago, regarding the requirement for an SGX driver on an FLC
> hardware platform to have some semblance of policy management to be
> relevant from a security/privacy perspective.  It would have certainly
> been collegial to include a reference to our discussions and concerns
> in the changelog.
> 
> See 364f68f5a3c in Jarkko's next/master.
> 
> The changeset addresses enclave access to the PROVISION key but is
> still insufficient to deliver guarantees that are consistent with the
> SGX security model.  In order to achieve that, policy management needs
> to embrace the use of MRSIGNER values, which is what our SFLC patchset
> uses.
> 
> The noted changeset actually implements most of the 'kernel bloat'
> that our SFLC patchset needs to bolt onto.
> 
> As of yesterday afternoon next/master still won't initialize a
> non-trivial enclave.  Since there now appears to be a wholesale change
> in the driver architecture and UAPI we are sitting on the sidelines
> waiting for an indication all of that has some hope of working before
> we introduce our approach.
> 
> Part of SFLC won't be popular but it is driven by clients who are
> actually paying for SGX security engineering and architectures.

How many of these people are actually posting here?

/Jarkko