lkml.org 
[lkml]   [2014]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 64bit x86: NMI nesting still buggy?
On May 21, 2014 7:58 AM, "Vojtech Pavlik" <vojtech@suse.cz> wrote:
>
> On Wed, May 21, 2014 at 04:20:55PM +0200, Borislav Petkov wrote:
> > On Wed, May 21, 2014 at 03:42:24PM +0200, Jiri Kosina wrote:
> > > Alright, Andy's iret optimization efforts do immediately bring a
> > > followup question -- why is this not a problem with iret-based return
> > > from #MC possibly interrupting NMI?
> >
> > Yeah, and frankly, I don't see this nesting fun at all protected against
> > a #MC interrupting it at any point actually. Because once the #MC
> > handler returns, it goes into paranoid_exit and that place doesn't
> > account for NMIs at all, AFAICS.
> >
> > Which would mean:
> >
> > * NMI goes off
> > * MCE happens, we switch to machine_check which is paranoidzeroentry
> > * #MC handler is done -> paranoid_exit -> IRET
> > -> boom! Or if not "boom", at least, the NMI gets forgotten.
> >
> > Am I missing something?
>
> I think to get a full BOOM you need a bit more complex process, namely:
>
> * NMI triggered
> * NMI handler starts
> * MCE happens
> * Second NMI triggered and queued
> * handler done, IRET
> * Second NMI handler starts and overwrites NMI return address on stack
> * Second NMI handler ends
> * First NMI handler ends and goes into an infinite IRET loop, always
> returning to the beginning of itself
>
> But you do have all the ingredients.
>
> And I don't see any other way out than not calling IRET for MCEs.

The MCE handler could detect this and fiddle with the IST entry. This
sounds considerably uglier than returning via RET, though.

--Andy

>
> --
> Vojtech Pavlik
> Director SUSE Labs


\
 
 \ /
  Last update: 2014-05-21 18:01    [W:0.146 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site