Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from_user()

[Sean Christopherson]

On Wed, Sep 01, 2021, Thomas Gleixner wrote:
> On Wed, Sep 01 2021 at 14:00, Thomas Gleixner wrote:
> >
> > commit b2f9d678e28c ("x86/mce: Check for faults tagged in
> > EXTABLE_CLASS_FAULT exception table entries") made use of this in MCE to
> > allow in kernel recovery. The only thing it uses is checking the
> > exception handler type.
> >
> > Bah. I'll fix that up to make that less obscure.
> >
> > The remaining two use cases (SGX and FPU) make use of the stored trap
> > number.
> 
> Though while for the FPU use case we really want to handle the #MC case,
> it's not clear to me whether this is actually correct for SGX.
> 
> Jarkko, Sean, Dave?

Are you asking about #MC specifically, or about SGX consuming the trap number in
general?

For #MC, it's probably a moot point because #MC on ENCLS is not recoverable for
current hardware.  If #MC somehow occurs on ENCLS and doesn't kill the platform,
"handling" the #MC in SGX is probably wrong.  Note, Tony is working on a series to
support recoverable #MC on SGX stuff on future hardware[*], but I'm not sure that's
relevant to this discussion.

As for SGX consuming the trap number in general, it's correct.  For non-KVM usage,
it's nice to have but not strictly necessary.  Any fault except #PF on ENCLS is
guaranteed to be a kernel or hardware bug; SGX uses the trap number to WARN on a
!#PF exception, e.g. on #GP or #UD.  Not having the trap number would mean losing
those sanity checks, which have been useful in the past.

For virtualizing SGX, KVM needs the trap number so that it can inject the correct
exception into the guest, e.g. if the guest violates the ENCLS concurrency rules
it should get a #GP, whereas a EPCM violation should #PF.

[*] https://lore.kernel.org/lkml/20210827195543.1667168-1-tony.luck@xxxxxxxxx