Re: [RFC PATCH v3 05/27] x86/sgx: Add SGX_CHILD_PRESENT hardware error code

Kai Huang
2021-01-27T02:49:12Z

On Tue, 2021-01-26 at 07:49 -0800, Dave Hansen wrote:
> On 1/26/21 1:30 AM, Kai Huang wrote:
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > SGX virtualization requires to allocate "raw" EPC and use it as "virtual
> > EPC" for SGX guest. Unlike EPC used by SGX driver, virtual EPC doesn't
> > track how EPC pages are used in VM, e.g. (de)construction of enclaves,
> > so it cannot guarantee EREMOVE success, e.g. it doesn't have a priori
> > knowledge of which pages are SECS with non-zero child counts.
>
> The grammar there is a bit questionable in spots. Here's a rewrite:
>
> SGX can accurately track how bare-metal enclave pages are used. This
> enables SECS to be specifically targeted and EREMOVE'd only after all
> child pages have been EREMOVE'd. This ensures that bare-metal SGX will
> never encounter SGX_CHILD_PRESENT in normal operation.

How about:

"SGX driver can accurate track how enclave pages are used. This enables..."

Since in another email, you mentioned that we should get rid of bare-metal driver,
and Andy suggested we can just use SGX driver?

>
> Virtual EPC is different. The host does not track how EPC pages are
> used by the guest, so it cannot guarantee EREMOVE success. It might,
> for instance, encounter a SECS with a non-zero child count.
>
> Aside: Would it be *possible* for the host to figure out where the SECS
> pages are? If not, we can say "host can not track" versus what I said:
> "host does not track".

Technically it is possible, so "host does not track" is more reasonable.

>
> > Add SGX_CHILD_PRESENT for use by SGX virtualization to assert EREMOVE
> > failures are expected, but only due to SGX_CHILD_PRESENT.
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
> > Signed-off-by: Kai Huang <kai.huang@intel.com>
>
> With the improved changelog:
>
> Acked-by: Dave Hansen <dave.hansen@intel.com>

Thanks.