On Thu, Apr 28, 2022 at 04:49:00PM -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.
>
> I stopped pursuing this because from what I understand if
> SGX_EPC_PAGE_CONFLICT is encountered with commit 08999b2489b4 ("x86/sgx:
> Free backing memory after faulting the enclave page") then it should
> also be encountered without it. The issue is not present with
> 08999b2489b4 ("x86/sgx: Free backing memory after faulting the
> enclave page") removed. I am thus currently investigating based on
> the assumption that the #GP is encountered because of MAC
> verification problem. I may be wrong here also and need more information
> since the SDM documents two seemingly related errors:
> #GP(0) -> If the instruction fails to verify MAC.
> SGX_MAC_COMPARE_FAIL -> If the MAC check fails.
This part puzzles me in the pseudo-code.
The version is read first:
TMP_VER := DS:RDX[63:0];
Then there's MAC calculation, comparison, and finally this check:
(* Check version before committing *)
IF (DS:RDX ≠ 0)
THEN #GP(0);
ELSE
DS:RDX := TMP_VER;
FI;
For me it is a mystery what does zero the slot and in what condition
it would be non-zero. Perhaps the #GP refers anyway to this check?
BR, Jarkko
