linux-kernel - Re: 64bit x86: NMI nesting still buggy?

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]

Date:	Tue, 29 Apr 2014 20:48:34 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Steven Rostedt <rostedt@...dmis.org>
cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	Salman Qazi <sqazi@...gle.com>, Ingo Molnar <mingo@...e.hu>,
	Michal Hocko <mhocko@...e.cz>, Borislav Petkov <bp@...en8.de>,
	Vojtech Pavlik <vojtech@...e.cz>,
	Petr Tesarik <ptesarik@...e.cz>, Petr Mladek <pmladek@...e.cz>
Subject: Re: 64bit x86: NMI nesting still buggy?

On Tue, 29 Apr 2014, Steven Rostedt wrote:

> > Just to be clear here -- I don't have a box that can reproduce this; I 
> > whole-heartedly believe that even if there are boxes with this behavior 
> > (and I assume there are, otherwise Intel wouldn't be mentioning it in the 
> > docs), it'd be hard to trigger on those.
> 
> I see your point. But it is documented for those that control both NMIs
> and SMMs. As it says in the document: "If the SMI handler requires the
> use of NMI interrupts". That to me sounds like a system that has
> control over both SMIs *and* NMIs. The BIOS should not have any control
> over NMIs, as the OS requires that. And the OS has no control over
> SMIs.
> 
> That paragraph sounds irrelevant to normal BIOS and OS systems as
> neither "owns" both SMIs and NMIs.

Which doesn't really help me being less nervous about this whole thing.

I don't believe Intel would put a completely arbitrary and nonsencial 
paragraph into the manual all of a sudden. It'd be great to know the 
rationale why this has been added in the first place.

> > We were hunting something completely different, and came through this 
> > paragraph in the Intel manual, and found it rather scary.
> 
> But this is all irrelevant anyway as this is all hypothetical and
> there's been no real world bug with this.

One would hope. Again -- I believe if this would trigger here and here a 
few times a year, everyone would probably atribute it to a "random hang", 
reboot, and never see the bug again.

-- 
Jiri Kosina
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/