Re: [RFC PATCH v4 04/26] x86/sgx: Add SGX_CHILD_PRESENT hardware error code

Kai Huang
2021-02-09T21:50:11Z

On Tue, 2021-02-09 at 17:07 +0000, Sean Christopherson wrote:
> On Tue, Feb 09, 2021, Dave Hansen wrote:
> > On 2/9/21 8:48 AM, Sean Christopherson wrote:
> > > On Tue, Feb 09, 2021, Dave Hansen wrote:
> > > > On 2/8/21 2:54 AM, Kai Huang wrote:
> > > > ...
> > > > > Add SGX_CHILD_PRESENT for use by SGX virtualization to assert EREMOVE
> > > > > failures are expected, but only due to SGX_CHILD_PRESENT.
> > > > This paragraph broke my brain when I read it. How about:
> > > >
> > > > Add a definition of SGX_CHILD_PRESENT. It will be used
> > > > exclusively by the SGX virtualization driver to suppress EREMOVE
> > > > warnings.
> > > Maybe worth clarifying that the driver isn't suppressing warnings willy-nilly?
> > > And the error code isn't about suppressing warnings, it's about identifying the
> > > expected EREMOVE failure scenario. The patch that creates the separate helper
> > > for doing EREMOVE without the WARN is what provides the suppression mechanism.
> > >
> > > Something like this?
> > >
> > >   Add a definition of SGX_CHILD_PRESENT. It will be used exclusively by
> > >   the SGX virtualization driver to handle recoverable EREMOVE errors when
> > >   saniziting EPC pages after they are reclaimed from a guest.
> >
> > Looks great to me. One nit: to a me, "reclaim" is different than
> > "free". Reclaim is a specific operation where a page is taken from one
> > user and reclaimed for other use. "Free" is the more general case
> > (which includes reclaim) when a physical page is no longer being used
> > (because the user is done *or* had the page reclaimed) and may be either
> > used by someone else or put in a free pool.
> >
> > I *think* this is actually a "free" operation, rather than a "reclaim".
> >  IIRC, this code gets used at munmap().
>
> It does. I used reclaim because userspace, which does the freeing from this
> code's perspective, never touches the EPC pages. The SGX_CHILD_PRESENT case is
> handling the scenario where userspace has for all intents and purposed reclaimed
> the EPC from a guest. If the guest cleanly tears down its enclaves, EREMOVE
> will not fail.
>
> "free" is probably better though, the above is far from obvious and still not
> guaranteed to be a true reclaim scenario. If using "freed", drop the "from a
> guest" part.

Thanks for feedback. I'll use below:

Add a definition of SGX_CHILD_PRESENT. It will be used exclusively by
the SGX virtualization driver to handle recoverable EREMOVE errors when
saniziting EPC pages after they are freed.