linux-kernel - Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YS+upEmTfpZub3s9@google.com>
Date:   Wed, 1 Sep 2021 16:47:32 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dan Williams <dan.j.williams@...el.com>,
        Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in
 restore_fpregs_from_user()

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@intel.com