lkml.org 
[lkml]   [2014]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 64bit x86: NMI nesting still buggy?
    On Tue, 29 Apr 2014 06:29:04 -0700
    "H. Peter Anvin" <hpa@linux.intel.com> wrote:

    > On 04/29/2014 06:05 AM, Jiri Kosina wrote:
    > >
    > > We were not able to come up with any other fix than avoiding using IST
    > > completely on x86_64, and instead going back to stack switching in
    > > software -- the same way 32bit x86 does.
    > >
    >
    > This is not possible, though, because there are several windows during
    > which if we were to take an exception which doesn't do IST, e.g. NMI, we
    > are worse than dead -- we are in fact rootable. Right after SYSCALL in
    > particular.

    Ah, right. SYSCALL does not update RSP. :-(
    Hm, so anything that can fire up right after a SYSCALL must use IST.
    It's possible to use an alternative IDT that gets loaded as the first
    thing in an NMI handler, but this gets incredibly ugly...

    > > So basically, I have two questions:
    > >
    > > (1) is the above analysis correct? (if not, why?)
    > > (2) if it is correct, is there any other option for fix than avoiding
    > > using IST for exception stack switching, and having kernel do the
    > > legacy task switching (the same way x86_32 is doing)?
    >
    > It is not an option, see above.
    >
    > > [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
    > >
    > > [2] "A special case can occur if an SMI handler nests inside an NMI
    > > handler and then another NMI occurs. During NMI interrupt
    > > handling, NMI interrupts are disabled, so normally NMI interrupts
    > > are serviced and completed with an IRET instruction one at a
    > > time. When the processor enters SMM while executing an NMI
    > > handler, the processor saves the SMRAM state save map but does
    > > not save the attribute to keep NMI interrupts disabled.
    > > Potentially, an NMI could be latched (while in SMM or upon exit)
    > > and serviced upon exit of SMM even though the previous NMI
    > > handler has still not completed."
    >
    > I believe [2] only applies if there is an IRET executing inside the SMM
    > handler, which should not normally be the case. It might also have been
    > addressed since that was written, but I don't know.

    The trouble here is that the official Intel documentation describes how
    to do this and specifically requests the OS to cope with nested NMIs.

    Petr T


    \
     
     \ /
      Last update: 2014-04-29 17:01    [W:5.062 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site