lkml.org 
[lkml]   [2018]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2018-12-20 11:34    [W:0.196 / U:11.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site