[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrWayHx6X1pwfF=ze_SWc7Uso25M+XA0_YrAPoC4_Dq9ug@mail.gmail.com>
Date: Wed, 21 May 2014 08:22:22 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Vojtech Pavlik <vojtech@...e.cz>
Cc: Michal Hocko <mhocko@...e.cz>, Salman Qazi <sqazi@...gle.com>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...e.hu>,
X86 ML <x86@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Petr Tesarik <ptesarik@...e.cz>,
Steven Rostedt <rostedt@...dmis.org>,
Jiri Kosina <jkosina@...e.cz>, Petr Mladek <pmladek@...e.cz>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 64bit x86: NMI nesting still buggy?
On May 21, 2014 7:58 AM, "Vojtech Pavlik" <vojtech@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists