Re: [PATCH v19 13/27] x86/sgx: Add wrappers for ENCLS leaf functions

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Thu, Mar 21, 2019 at 08:40:11AM -0700, Sean Christopherson wrote:
> On Thu, Mar 21, 2019 at 04:51:53PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Mar 19, 2019 at 12:59:07PM -0700, Sean Christopherson wrote:
> > > On Sun, Mar 17, 2019 at 11:14:42PM +0200, Jarkko Sakkinen wrote:
> > > > +/**
> > > > + * ENCLS_FAULT_FLAG - flag signifying an ENCLS return code is a trapnr
> > > > + *
> > > > + * ENCLS has its own (positive value) error codes and also generates
> > > > + * ENCLS specific #GP and #PF faults.  And the ENCLS values get munged
> > > > + * with system error codes as everything percolates back up the stack.
> > > > + * Unfortunately (for us), we need to precisely identify each unique
> > > > + * error code, e.g. the action taken if EWB fails varies based on the
> > > > + * type of fault and on the exact SGX error code, i.e. we can't simply
> > > > + * convert all faults to -EFAULT.
> > > > + *
> > > > + * To make all three error types coexist, we set bit 30 to identify an
> > > > + * ENCLS fault.  Bit 31 (technically bits N:31) is used to differentiate
> > > > + * between positive (faults and SGX error codes) and negative (system
> > > > + * error codes) values.
> > > > + */
> > > > +#define ENCLS_FAULT_FLAG 0x40000000
> > > > +
> > > > +/**
> > > > + * Retrieve the encoded trapnr from the specified return code.
> > > > + */
> > > > +#define ENCLS_TRAPNR(r) ((r) & ~ENCLS_FAULT_FLAG)
> > > 
> > > I honestly can't remember, is there a reason ENCLS_TRAPNR is still a macro
> > > and not an inline function?
> > 
> > Not at all. And also the value should be unsigned and fault flag
> > should be 0x80* because we never should get negative values.
> 
> From ENCLS itself, but we do have scenarios where the return code can
> hold a system error code (negative value), an SGX error code (positive
> value) or fault inforation.  E.g. sgx_encl_init() sets ret to -ERESTARTSYS,
> and __sgx_encl_ewb() returns system error codes if get_backing() fails
> and also directly returns the result of __ewb().  We could dance around
> those issues, but IMO it's too fragile as it essentially requires a full
> audit of every possible error path when modifying code.

There should be zero of those now but if you find one we can fix that.
These inline functions should only deal with what comes from ENCLS. I
think it is cleanest to fix those sites. I think here the focus should
be on clarity.

In ioctl.c there are total 5 sites and all of them are good.

Also encl.c is all good.

From the sites that you mentioned sgx_encl_ewb() needs to be fixed. In
reclaim.c that seems to be the only problematic site.

These are pretty easy to grep with 'encls_'.

For me it looks like that assuming the positive value is absolutely
the right thing to do as long as sgx_encl_ewb() is fixed properly.

/Jarkko