linux-kernel - Re: [PATCH v7 7/8] [DO NOT MERGE] x86/kexec: Add int3 in kexec path for testing

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: <Z9MQqYbGBAvTz4Ox@gmail.com>
Date: Thu, 13 Mar 2025 18:06:49 +0100
From: Ingo Molnar <mingo@...nel.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: kexec@...ts.infradead.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H . Peter Anvin" <hpa@...or.com>,
	David Woodhouse <dwmw@...zon.co.uk>,
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	Kai Huang <kai.huang@...el.com>,
	Nikolay Borisov <nik.borisov@...e.com>,
	linux-kernel@...r.kernel.org, Simon Horman <horms@...nel.org>,
	Dave Young <dyoung@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, jpoimboe@...nel.org,
	bsz@...zon.de
Subject: Re: [PATCH v7 7/8] [DO NOT MERGE] x86/kexec: Add int3 in kexec path
 for testing


* David Woodhouse <dwmw2@...radead.org> wrote:

> The exception handler already returns if the exception was int3, but 
> not for anything else. Less so the "print something warm and fuzzy" 
> part; it just does the same register dump. But we could change that.
> 
> I'm less keen on making it unconditional though. Kexec is a 
> performance-critical path when every millisecond is perceived as 
> guest steal time, and the serial output should only happen in 
> production if something goes *wrong*.
> 
> And besides, most kexec users don't have early_printk enabled anyway 
> so if we break them, this idea doesn't help.

So this check would only cause any real overhead if serial debugging is 
enabled - in which case there's already substantial overhead due to the 
serial console overhead (virtual or otherwise).

As to not printing anything unless the early serial console is enabled 
- that's fine, we'd still *break* if something doesn't work in this 
code path, so at least the exception handling machinery is kept 
well-tested. :-)

Thanks,

	Ingo