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: <8d9253eda0fd74595db05eb3449ccc5be2f563be.camel@infradead.org>
Date: Thu, 13 Mar 2025 18:38:38 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Ingo Molnar <mingo@...nel.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>,  "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

On Thu, 2025-03-13 at 18:06 +0100, Ingo Molnar wrote:
> 
> * 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. :-)

I suppose so, although it's also fairly easy to test by adding an int3
into a kexec-jump test case like http://david.woodhou.se/loadret.c

But yeah, it's easy enough to make the int3 register dump a little less
scary and then remove the 'DO NOT MERGE' tag from the commit which adds
the unconditional int3.

I'm still trying to chase down the new objtool warning you noted (which
I swear I saw once but now can't reproduce), and I note I need to make
the early_printk hooks depend on (KEXEC_CORE && X86_64) since I removed
the separate KEXEC_DEBUG option and made it all unconditional.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)