linux-kernel - Re: [tip: x86/boot] x86/boot: Ignore NMIs during very early boot

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] [day] [month] [year] [list]

Date: Wed, 3 Apr 2024 12:41:19 +0200
From: Borislav Petkov <bp@...en8.de>
To: Zeng Heng <zengheng4@...wei.com>
Cc: linux-tip-commits@...r.kernel.org,
	Jun'ichi Nomura <junichi.nomura@....com>,
	Derek Barbosa <debarbos@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Andy Lutomirski <luto@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, "liwei (GF)" <liwei391@...wei.com>
Subject: Re: [tip: x86/boot] x86/boot: Ignore NMIs during very early boot

Hi Zeng Heng,

On Wed, Apr 03, 2024 at 02:32:45PM +0800, Zeng Heng wrote:
> Until just now, I saw your completely different responses to the same patch.

Lemme explain how I see the situation.

You sent a patch:

https://lore.kernel.org/all/20230110102745.2514694-1-zengheng4@huawei.com/

which had a commit message which tried to explain what happens. And
I tried to parse your commit message and understand what you're trying
to do but there never was a clear explanation.

When I read "If kdump is enabled, when using mce_inject to inject
errors..." then I think, oh great, more experiments. ;-\

And no, I don't want to add code to early boot just to make some weird
experiments happy.

Yeah yeah, an MCE can happen very early but until a real reproducer, I'm
not convinced.

Now that other patch's commit message has at least a bit more clear
explanation how you can *actually* cause this. And I still would've
asked how *exactly* this happens but it is kinda clear: you can run perf
and generate an NMI storm and then have two back-to-back NMIs.

And I'm still not crazy about having an empty early NMI handler either
thus I suggested to make it at least say something so that we're aware
that early NMIs have happened.

So if it is not clear *why* a patch is being done, then it goes nowhere.
Because you'll go your merry way and "develop driver software based on
arm64 features" or whatever else you get to do but the maintainers will
be left to be dealing with your code indefinitely.

I hope this makes it more clear.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette