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]

Message-ID: <alpine.LNX.2.00.1404291835560.16783@pobox.suse.cz>
Date:	Tue, 29 Apr 2014 18:51:13 +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:

> You keep saying 38.4, but I don't see any 38.4. Perhaps you meant 34.8?

Yeah, sorry for the typo.

> Which BTW is this:
> 
> ----
> 34.8 NMI HANDLING WHILE IN SMM
[ ... snip ... ]
> ----
> 
> Read the first paragraph. That sounds like normal operation. The SMM
> should use the RSM to return and that does not re-enable NMIs if the
> SMM triggered during an NMI.

Yup, so far so good.

> The above is just stating that the SMM can enable NMIs if it wants to
> by executing an IRET. Which to me sounds rather buggy to do.

That's exactly the point actually. Basically, that paragraph allows the 
SMM code writers to issue iret. If they do it, the very problem I am 
trying to describe here might happen.

> Now the third paragraph is rather ambiguous. It sounds like it's still
> talking about doing an IRET in the SMI handler. As the IRET will enable
> NMIs, and if the SMI happened while an NMI was happening, the new NMI
> will happen. In this case, the NMI handler needs to address this. But
> this really sounds like if you have control of both SMM handlers and
> NMI handlers, which the Linux kernel certainly does not. Again, I label
> this as a bug in the BIOS.
> 
> And again, if the SMM were to trigger a fault, it too would enable
> NMIs. That is something that the SMM handler should not do.

That's what the last paragraph is talking about BTW, related to Pentium 
CPUs. That part is scary by itself.

> Can you reproduce your problem on different platforms, or is this just
> one box that exhibits this behavior? If it's only one box, I'm betting
> it has a BIOS doing nasty things.

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.

We were hunting something completely different, and came through this 
paragraph in the Intel manual, and found it rather scary.

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