[PATCH] x86/kexec: Push kjump return address even for non-kjump kexec

[David Woodhouse]

On Tue, 2026-04-28 at 07:22 -0700, Dave Hansen wrote:
> On 4/2/26 03:34, David Woodhouse wrote:
> > The version of purgatory code shipped by kexec-tools attempts to look
> > above the top of its stack to find a return address for a kjump
> 
> This is a bug in kexec-tools, right? Has kexec-tools been fixed?

There isn't any other way to tell the difference between kjump and a
normal kexec, is there?

> The purgatory code is injected by userspace, so are you kinda asserting
> here that the this change in the kernel stack "breaks userspace"?

Essentially, yes. Rohan found that kexec broke on a kernel update,
bisected it to my commit, and worked out why.

This isn't just the "kernel stack". This is the stack that the kernel
sets up specifically for the kexec target.

> I guess one little push isn't the end of the world. But, can we please
> comment it to this effect:
> 
> 	/*
> 	 * Work around a kexec-tools' <version here> purgatory bug that
> 	 * accesses the stack one long out of bounds. Push a dummy value
> 	 * to make the access harmless and avoid a fault.
> 	 */
> 

Sure. Will phrase it thus in v2:

+       /*
+        * Set return address to 0 if not preserving context. The purgatory
+        * shipped in kexec-tools will unconditionally look for the return
+        * address on the stack and set a kexec_jump_back_entry= command
+        * line option if it's non-zero. There's no other way that it can
+        * tell a preserve-context (kjump) kexec from a normal one.
+        */


> Without that, we'll be scratching our heads for the next decade about
> what this 0 on the stack does. The comment you suggested tells us what
> it is doing, but not why.
> 
> It all feels kinda icky though. Our stack is an ABI?!?!?!

Well, it's kexec. Where else are we going to put things? Wanna declare
that we're going to use %rbx instead? Or the BIOS Data Area in segment
0x40? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5069 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20260428/f42b4d54/attachment-0001.p7s>