Re: [PATCH v22 05/24] x86/sgx: Add ENCLS architectural error codes

[Sean Christopherson]

On Fri, Sep 27, 2019 at 07:08:42PM +0300, Jarkko Sakkinen wrote:
> On Fri, Sep 27, 2019 at 12:20:13PM +0200, Borislav Petkov wrote:
> > On Tue, Sep 03, 2019 at 05:26:36PM +0300, Jarkko Sakkinen wrote:
> > > Document ENCLS architectural error codes. These error codes are returned by
> > > the SGX opcodes. Make the header as part of the uapi so that they can be
> > > used in some situations directly returned to the user space (ENCLS[EINIT]
> > > leaf function error codes could be one potential use case).
> > > 
> > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
> > > Co-developed-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> > > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> > > ---
> > >  arch/x86/include/uapi/asm/sgx_errno.h | 91 +++++++++++++++++++++++++++
> > >  1 file changed, 91 insertions(+)
> > >  create mode 100644 arch/x86/include/uapi/asm/sgx_errno.h
> > > 
> > > diff --git a/arch/x86/include/uapi/asm/sgx_errno.h b/arch/x86/include/uapi/asm/sgx_errno.h
> > > new file mode 100644
> > > index 000000000000..48b87aed58d7
> > > --- /dev/null
> > > +++ b/arch/x86/include/uapi/asm/sgx_errno.h
> > > @@ -0,0 +1,91 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
> > > +/*
> > > + * Copyright(c) 2018 Intel Corporation.
> > > + *
> > > + * Contains the architecturally defined error codes that are returned by SGX
> > > + * instructions, e.g. ENCLS, and may be propagated to userspace via errno.
> > > + */
> > > +
> > > +#ifndef _UAPI_ASM_X86_SGX_ERRNO_H
> > > +#define _UAPI_ASM_X86_SGX_ERRNO_H
> > > +
> > > +/**
> > > + * enum sgx_encls_leaves - return codes for ENCLS, ENCLU and ENCLV
> > > + * %SGX_SUCCESS:		No error.
> > > + * %SGX_INVALID_SIG_STRUCT:	SIGSTRUCT contains an invalid value.
> > > + * %SGX_INVALID_ATTRIBUTE:	Enclave is not attempting to access a resource
> > 
> > That first "not" looks wrong.
> > 
> > > + *				for which it is not authorized.
> > > + * %SGX_BLKSTATE:		EPC page is already blocked.
> > > + * %SGX_INVALID_MEASUREMENT:	SIGSTRUCT or EINITTOKEN contains an incorrect
> > > + *				measurement.
> > > + * %SGX_NOTBLOCKABLE:		EPC page type is not one which can be blocked.
> > > + * %SGX_PG_INVLD:		EPC page is invalid (and cannot be blocked).
> > > + * %SGX_EPC_PAGE_CONFLICT:	EPC page in use by another SGX instruction.
> > > + * %SGX_INVALID_SIGNATURE:	Enclave's signature does not validate with
> > > + *				public key enclosed in SIGSTRUCT.
> > > + * %SGX_MAC_COMPARE_FAIL:	MAC check failed when reloading EPC page.
> > > + * %SGX_PAGE_NOT_BLOCKED:	EPC page is not marked as blocked.
> > > + * %SGX_NOT_TRACKED:		ETRACK has not been completed on the EPC page.
> > > + * %SGX_VA_SLOT_OCCUPIED:	Version array slot contains a valid entry.
> > > + * %SGX_CHILD_PRESENT:		Enclave has child pages present in the EPC.
> > > + * %SGX_ENCLAVE_ACT:		Logical processors are currently executing
> > > + *				inside the enclave.
> > > + * %SGX_ENTRYEPOCH_LOCKED:	SECS locked for EPOCH update, i.e. an ETRACK is
> > > + *				currently executing on the SECS.
> > > + * %SGX_INVALID_EINITTOKEN:	EINITTOKEN is invalid and enclave signer's
> > > + *				public key does not match IA32_SGXLEPUBKEYHASH.
> > > + * %SGX_PREV_TRK_INCMPL:	All processors did not complete the previous
> > > + *				tracking sequence.
> > > + * %SGX_PG_IS_SECS:		Target EPC page is an SECS and cannot be
> > > + *				blocked.
> > > + * %SGX_PAGE_ATTRIBUTES_MISMATCH:	Attributes of the EPC page do not match
> > > + *					the expected values.
> > 
> > You sometimes call it "PG" and sometimes "PAGE". Unify?

We pulled the names verbatim from the SDM.  I agree that diverging from
the SDM makes sense.  I'll also see if the SDM can be updated to use
consistent names.

> > > + * %SGX_PAGE_NOT_MODIFIABLE:	EPC page cannot be modified because it is in
> > > + *				the PENDING or MODIFIED state.
> > > + * %SGX_PAGE_NOT_DEBUGGABLE:	EPC page cannot be modified because it is in
> > > + *				the PENDING or MODIFIED state.
> > 
> > Same description text?
> 
> Thanks for the remarks. I think I define only the error codes in the
> next version that actually get used by the driver and document them
> properly. Should become way more cleaner.

Please keep all error codes.  For errors that inevitably occur during
development, it's very helpful to have the complete list in the kernel
(well, reasonably complete).  I hate having to open and search through the
SDM just to decipher a random numeric error code.