public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Salman Qazi <sqazi@google.com>, Ingo Molnar <mingo@elte.hu>,
	Michal Hocko <mhocko@suse.cz>, Borislav Petkov <bp@alien8.de>,
	Petr Tesarik <ptesarik@suse.cz>, Petr Mladek <pmladek@suse.cz>
Subject: Re: 64bit x86: NMI nesting still buggy?
Date: Tue, 29 Apr 2014 17:41:58 +0200	[thread overview]
Message-ID: <20140429154158.GB21754@suse.cz> (raw)
In-Reply-To: <alpine.LNX.2.00.1404291720440.16783@pobox.suse.cz>

On Tue, Apr 29, 2014 at 05:24:32PM +0200, Jiri Kosina wrote:
> On Tue, 29 Apr 2014, Steven Rostedt wrote:
> 
> > > According to 38.4 of [1], when SMM mode is entered while the CPU is 
> > > handling NMI, the end result might be that upon exit from SMM, NMIs will 
> > > be re-enabled and latched NMI delivered as nested [2].
> > 
> > Note, if this were true, then the x86_64 hardware would be extremely
> > buggy. That's because NMIs are not made to be nested. If SMM's come in
> > during an NMI and re-enables the NMI, then *all* software would break.
> > That would basically make NMIs useless.
> > 
> > The only time I've ever witness problems (and I stress NMIs all the
> > time), is when the NMI itself does a fault. Which my patch set handles
> > properly. 
> 
> Yes, it indeed does. 
> 
> In the scenario I have outlined, the race window is extremely small, plus 
> NMIs don't happen that often, plus SMIs don't happen that often, plus 
> (hopefully) many BIOSes don't enable NMIs upon SMM exit.
> 
> The problem is, that Intel documentation is clear in this respect, and 
> explicitly states it can happen. And we are violating that, which makes me 
> rather nervous -- it'd be very nice to know what is the background of 38.4 
> section text in the Intel docs.

If we cannot disable IST for NMI on x86_64, because it'd break SYSCALL,
and thus cannot handle this situation well, then we should at least try
to detect it post-factum.

In the NMI handler, after ascertaining that the first NMI is executing
(in_nmi not yet set) we check the return address stored on the stack.

If it points anywhere inside the NMI handler (in reality only in the
space between the NMI handler start and the check), a SMI-triggered
nested NMI has happened.

Then we should be able to at least report it before dying.

If it doesn't ever happen: Great, this wasn't a real concern. If it
does, we can pester BIOS vendors.

-- 
Vojtech Pavlik
Director SuSE Labs

  reply	other threads:[~2014-05-01 10:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29 13:05 64bit x86: NMI nesting still buggy? Jiri Kosina
2014-04-29 13:29 ` H. Peter Anvin
2014-04-29 14:06   ` Steven Rostedt
2014-04-29 14:28     ` H. Peter Anvin
2014-04-29 14:31   ` Petr Tesarik
2014-04-30 22:10   ` Jiri Kosina
2014-04-30 22:46     ` H. Peter Anvin
2014-04-29 14:03 ` Steven Rostedt
2014-04-29 15:24   ` Jiri Kosina
2014-04-29 15:41     ` Vojtech Pavlik [this message]
2014-04-29 16:09     ` Steven Rostedt
2014-04-29 16:19       ` Steven Rostedt
2014-04-29 16:51       ` Jiri Kosina
2014-04-29 17:12         ` Steven Rostedt
2014-04-29 18:48           ` Jiri Kosina
2014-04-29 19:16             ` Steven Rostedt
2014-05-06 10:02     ` Ingo Molnar
2014-05-21 13:42   ` Jiri Kosina
2014-05-21 14:20     ` Borislav Petkov
2014-05-21 14:58       ` Vojtech Pavlik
2014-05-21 15:22         ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140429154158.GB21754@suse.cz \
    --to=vojtech@suse.cz \
    --cc=bp@alien8.de \
    --cc=hpa@linux.intel.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@elte.hu \
    --cc=pmladek@suse.cz \
    --cc=ptesarik@suse.cz \
    --cc=rostedt@goodmis.org \
    --cc=sqazi@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox