Re: [RFC PATCH 1/4] x86/sgx: Do not free backing memory on ENCLS[ELDU] failure

[Kai Huang <kai.huang@intel.com>]

On Thu, 2022-04-28 at 16:49 -0700, Reinette Chatre wrote:
> > 
> > I also looked a little deeper at this transient failure problem.  The
> > ELDU documentation also mentions a possible error code of:
> > 
> >  	SGX_EPC_PAGE_CONFLICT
> > 
> > It *looks* like there can be conflicts on the SECS page as well as the
> > EPC page being explicitly accessed.  Is that a possible problem here?
> 
> I went down this path myself. SGX_EPC_PAGE_CONFLICT is an error code
> supported by newer ELDUC - the ELDU used in current code would indeed
> #GP in this case. The SDM text describing ELDUC as "This leaf function
> behaves like ELDU but with improved conflict handling for oversubscription"
> really does seem relevant to the test that triggers this issue.

This new error code and the new leaf functions with "C" postfix (ELDUC, etc) are
introduced to support VMM oversubscription of EPC.  VMM oversubscription of EPC
runs independently with guest so theoretically when VMM is performing some
operation on EPC in one CPU, guest running in another CPU can touch the EPC
simultaneously.

The new "C" variants are supposed to be used by VMM when it supports VMM
oversubscription of EPC, so that the VMM can a ENCLS instruction error code,
rather than a #GP when this case happens.  At guest side, when ENCLS conflicting
happens, VMM will get a VM-exit so it can be handed by VMM, i.e. by letting the
guest to run the same ENCLS again.

For now the SGX driver doesn't need to use the "C" variant, nor should it expect
the new SGX_EPC_PAGE_CONFLICT error code, because the driver already needs to
serialize those ENCLS leaf functions which can not run concurrently.  I assume
this should apply to SGX2 support too.

-- 
Thanks,
-Kai