[PATCH v28 11/22] x86/sgx: Linux Enclave Driver

[Dr. Greg]

On Fri, Mar 06, 2020 at 09:00:03PM +0200, Jarkko Sakkinen wrote:

Good afternoon, I hope the day is going well for everyone.

> > >> +/**
> > >> + * struct sgx_enclave_create - parameter structure for the
> > >> + *                             %SGX_IOC_ENCLAVE_CREATE ioctl
> > >> + * @src:	address for the SECS page data
> > >> + */
> > >> +struct sgx_enclave_create  {
> > >> +	__u64	src;
> > > 
> > > Would it make sense to add reserved fields to the structs so that new
> > > features can be added in a backwards compatible way?  E.g. if we want to
> > > allow userspace to control the backing store by passing in a file
> > > descriptor ENCLAVE_CREATE.

> > Reserving space for future fields is not necessary because the
> > size of the struct is encoded in the ioctl number. The kernel can
> > use this to differentiate between different call versions from
> > userspace.

> Sure but I still would never change the signature once a ioctl is
> added.

These reflections cause me to call, once again, what will be an
unpopular question, but if we pride ourselves on intellectual honesty
in our engineering practices we need to address it.

If we are locking ioctl's and ABI's down, then we need to address,
before the driver goes in, how we are going to handle support for
those of us that have engineering needs around launch token
technology.

On an FLC (unlocked) platform, which is the only thing the driver will
initialize on, there is no reason not to preserve the initialization
IOCTL argument structure that accepts a pointer to a launch token or
to disallow an enclave that has the attribute bit/mask set that allows
the enclave to have access to the launch key.  When presented with an
enclave with the launch bit set the driver can simply set the launch
control registers to the MRSIGNER value of that enclave.

It is a straight forward process to provide a root based mechanism
that allows the owner of the platform to control that behavior, if
there are concerns about how the platform is to be used, much like
what is currently being done with access to the provision key.

The ideological purity statement is made by the decision to limit what
hardware the driver will run on.  Once that statement is made, and the
driver firmly implements that decision, the owner of that platform
should be able to decide how they want to use and implement the
technology from there.

Unless someone else chirps up there are essentially only two complete
runtimes that are concerned with this issue.  Intel can enforce
enhanced ideological purity, if they desire, by simply disallowing
anyone to pass a non-null EINIT structure pointer through their
runtime to the driver, which leaves us to implement the behavior we
want without ABI concerns.

There is a fairly fundamental question here regarding 'software
freedom', maybe Jonathan Corbet and company will even pick up on
it.... :-)

> /Jarkko

Hopefully all of this makes sense and is reasonable.

Have a good remainder of the week, wherever you happen to be locked in
at.

We now return you to your regularly scheduled programming on the
register dance surrounding enclave entry.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      SGX secured infrastructure and
Enjellic Systems Development, LLC     autonomously self-defensive
4206 N. 19th Ave.                     platforms.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"More people are killed every year by pigs than by sharks, which shows
 you how good we are at evaluating risk."
                                -- Bruce Schneier
                                   Beyond Fear