Re: x86/sgx: uapi change proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux