[PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[David Woodhouse]

Debugging kexec failures is painful, as anything going wrong in execution
of the critical relocate_kernel() function tends to just lead to a triple
fault. Thus leading to *weeks* of my life that I won't get back. Having
hacked something up for my own use, I figured I should share it...

Add a trivial exception handler in the relocate_kernel environment which 
outputs to the early_printk serial console if configured. Currently only 
8250-compatible serial ports are supported, but that could be extended.

I had to hack up QEMU support for a PCI serial port which matches what
the existing early_printk code can drive, and the *real* 8250_pci driver
doesn't seem to cope with that setup at all, but whatever... the kexec
code now drives the same 32-bit stride which is all that earlyprintk
supports. We can always add more later, if anyone cares.

Someone who cares might want to bring the i386 version into line with
this, although the lack of rip-based addressing makes all the PIC code a
bit harder.

David Woodhouse (8):
      x86/kexec: Debugging support: load a GDT
      x86/kexec: Debugging support: Load an IDT and basic exception entry points
      x86/kexec: Debugging support: Dump registers on exception
      x86/kexec: Add 8250 serial port output
      x86/kexec: Add 8250 MMIO serial port output
      x86/kexec: Invalidate GDT/IDT from relocate_kernel() instead of earlier
      [DO NOT MERGE] x86/kexec: Add int3 in kexec path for testing
      [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

 arch/x86/include/asm/kexec.h         |   7 ++
 arch/x86/kernel/early_printk.c       |   9 ++
 arch/x86/kernel/machine_kexec_64.c   |  50 ++++++--
 arch/x86/kernel/relocate_kernel_64.S | 254 +++++++++++++++++++++++++++++++++++++++-
 4 files changed, 308 insertions(+), 12 deletions(-)


v7:
 • Drop CONFIG_KEXEC_DEBUG and make it all unconditional in order to
   "throw regressions back into the face of whoever manages to introduce
   them" (Ingo, https://lore.kernel.org/kexec/Z7rwA-qVauX7lY8G@gmail.com/)
 • Move IDT invalidation into relocate_kernel() itself.

v6: https://lore.kernel.org/kexec/20250115191423.587774-1-dwmw2@infradead.org/
 • Rebase onto already-merged fixes in tip/x86/boot.
 • Move CONFIG_KEXEC_DEBUG to generic kernel/Kconfig.kexec as Bartosz is
   working on an Arm64 version.

v5: https://lore.kernel.org/kexec/20241205153343.3275139-1-dwmw2@infradead.org/T/
 • Drop [RFC].
 • Drop _PAGE_NOPTISHADOW fix, which Ingo already took into tip/x86/urgent.
 • Add memory-mapped serial port support (32-bit MMIO spacing only).

v4 (RFC): https://lore.kernel.org/kexec/20241127190343.44916-1-dwmw2@infradead.org/T/
 • Add _PAGE_NOPTISHADOW fix for the identmap code.
 • Drop explicit map of control page, which was masking the identmap bug.

v3 (RFC): https://lore.kernel.org/kexec/20241125100815.2512-1-dwmw2@infradead.org/T/
 • Add CONFIG_KEXEC_DEBUG option and use earlyprintk config.
 • Allocate PGD separately from control page.
 • Explicitly map control page into identmap.

V2 (RFC): https://lore.kernel.org/kexec/20241122224715.171751-1-dwmw2@infradead.org/T/
 • Introduce linker script, start to clean up data access.

V1 (RFC): https://lore.kernel.org/kexec/20241103054019.3795299-1-dwmw2@infradead.org/T/
 • Initial proof-of-concept hacks.

[PATCH v7 1/8] x86/kexec: Debugging support: load a GDT

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

There are some failure modes which lead to triple-faults in the
relocate_kernel function, which is fairly much undebuggable for normal
mortals.

Adding a GDT in the relocate_kernel environment is step 1 towards being
able to catch faults and do something more useful.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/relocate_kernel_64.S | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index b44d8863e57f..ac058971a382 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -40,6 +40,16 @@ SYM_DATA(kexec_pa_table_page, .quad 0)
 SYM_DATA(kexec_pa_swap_page, .quad 0)
 SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
 
+	.balign 16
+SYM_DATA_START_LOCAL(kexec_debug_gdt)
+	.word   kexec_debug_gdt_end - kexec_debug_gdt - 1
+	.long   0
+	.word   0
+	.quad   0x00cf9a000000ffff      /* __KERNEL32_CS */
+	.quad   0x00af9a000000ffff      /* __KERNEL_CS */
+	.quad   0x00cf92000000ffff      /* __KERNEL_DS */
+SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
+
 	.section .text..relocate_kernel,"ax";
 	.code64
 SYM_CODE_START_NOALIGN(relocate_kernel)
@@ -116,6 +126,19 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	/* store the start address on the stack */
 	pushq   %rdx
 
+	/* Create a GDTR (16 bits limit, 64 bits addr) on stack */
+	leaq	kexec_debug_gdt(%rip), %rax
+	pushq	%rax
+	pushw	(%rax)
+
+	/* Load the GDT, put the stack back */
+	lgdt	(%rsp)
+	addq	$10, %rsp
+
+	/* Test that we can load segments */
+	movq	%ds, %rax
+	movq	%rax, %ds
+
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
 	 * below.
-- 
2.48.1

[tip: x86/boot] x86/kexec: Add relocate_kernel() debugging support: Load a GDT

[tip-bot2 for David Woodhouse]

The following commit has been merged into the x86/boot branch of tip:

Commit-ID:     afb305d6831b930571b5413cec239289ef164b55
Gitweb:        https://git.kernel.org/tip/afb305d6831b930571b5413cec239289ef164b55
Author:        David Woodhouse <dwmw@amazon.co.uk>
AuthorDate:    Wed, 12 Mar 2025 14:34:13 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Mar 2025 11:23:31 +01:00

x86/kexec: Add relocate_kernel() debugging support: Load a GDT

There are some failure modes which lead to triple-faults in the
relocate_kernel() function, which is fairly much undebuggable
for normal mortals.

Adding a GDT in the relocate_kernel() environment is step 1 towards
being able to catch faults and do something more useful.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250312144257.2348250-2-dwmw2@infradead.org
---
 arch/x86/kernel/relocate_kernel_64.S | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index b44d886..ac05897 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -40,6 +40,16 @@ SYM_DATA(kexec_pa_table_page, .quad 0)
 SYM_DATA(kexec_pa_swap_page, .quad 0)
 SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
 
+	.balign 16
+SYM_DATA_START_LOCAL(kexec_debug_gdt)
+	.word   kexec_debug_gdt_end - kexec_debug_gdt - 1
+	.long   0
+	.word   0
+	.quad   0x00cf9a000000ffff      /* __KERNEL32_CS */
+	.quad   0x00af9a000000ffff      /* __KERNEL_CS */
+	.quad   0x00cf92000000ffff      /* __KERNEL_DS */
+SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
+
 	.section .text..relocate_kernel,"ax";
 	.code64
 SYM_CODE_START_NOALIGN(relocate_kernel)
@@ -116,6 +126,19 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	/* store the start address on the stack */
 	pushq   %rdx
 
+	/* Create a GDTR (16 bits limit, 64 bits addr) on stack */
+	leaq	kexec_debug_gdt(%rip), %rax
+	pushq	%rax
+	pushw	(%rax)
+
+	/* Load the GDT, put the stack back */
+	lgdt	(%rsp)
+	addq	$10, %rsp
+
+	/* Test that we can load segments */
+	movq	%ds, %rax
+	movq	%rax, %ds
+
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
 	 * below.

[tip: x86/boot] x86/kexec: Add relocate_kernel() debugging support: Load a GDT

[tip-bot2 for David Woodhouse]

The following commit has been merged into the x86/boot branch of tip:

Commit-ID:     b25eb5f5e419b81f124d5ba2abaaacf1948fb97e
Gitweb:        https://git.kernel.org/tip/b25eb5f5e419b81f124d5ba2abaaacf1948fb97e
Author:        David Woodhouse <dwmw@amazon.co.uk>
AuthorDate:    Wed, 12 Mar 2025 14:34:13 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 14 Mar 2025 11:01:53 +01:00

x86/kexec: Add relocate_kernel() debugging support: Load a GDT

There are some failure modes which lead to triple-faults in the
relocate_kernel() function, which is fairly much undebuggable
for normal mortals.

Adding a GDT in the relocate_kernel() environment is step 1 towards
being able to catch faults and do something more useful.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250312144257.2348250-2-dwmw2@infradead.org
---
 arch/x86/kernel/relocate_kernel_64.S | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index b44d886..ac05897 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -40,6 +40,16 @@ SYM_DATA(kexec_pa_table_page, .quad 0)
 SYM_DATA(kexec_pa_swap_page, .quad 0)
 SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
 
+	.balign 16
+SYM_DATA_START_LOCAL(kexec_debug_gdt)
+	.word   kexec_debug_gdt_end - kexec_debug_gdt - 1
+	.long   0
+	.word   0
+	.quad   0x00cf9a000000ffff      /* __KERNEL32_CS */
+	.quad   0x00af9a000000ffff      /* __KERNEL_CS */
+	.quad   0x00cf92000000ffff      /* __KERNEL_DS */
+SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
+
 	.section .text..relocate_kernel,"ax";
 	.code64
 SYM_CODE_START_NOALIGN(relocate_kernel)
@@ -116,6 +126,19 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	/* store the start address on the stack */
 	pushq   %rdx
 
+	/* Create a GDTR (16 bits limit, 64 bits addr) on stack */
+	leaq	kexec_debug_gdt(%rip), %rax
+	pushq	%rax
+	pushw	(%rax)
+
+	/* Load the GDT, put the stack back */
+	lgdt	(%rsp)
+	addq	$10, %rsp
+
+	/* Test that we can load segments */
+	movq	%ds, %rax
+	movq	%rax, %ds
+
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
 	 * below.

[PATCH v7 2/8] x86/kexec: Debugging support: Load an IDT and basic exception entry points

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/include/asm/kexec.h         |  5 ++
 arch/x86/kernel/machine_kexec_64.c   | 21 ++++++++
 arch/x86/kernel/relocate_kernel_64.S | 74 ++++++++++++++++++++++++++++
 3 files changed, 100 insertions(+)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 8ad187462b68..ec7636f4f86a 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -8,6 +8,9 @@
 # define PA_PGD			2
 # define PA_SWAP_PAGE		3
 # define PAGES_NR		4
+#else
+/* Size of each exception handler referenced by the IDT */
+# define KEXEC_DEBUG_EXC_HANDLER_SIZE	6 /* pushi, pushi, 2-byte jmp */
 #endif
 
 # define KEXEC_CONTROL_PAGE_SIZE	4096
@@ -58,6 +61,8 @@ struct kimage;
 extern unsigned long kexec_va_control_page;
 extern unsigned long kexec_pa_table_page;
 extern unsigned long kexec_pa_swap_page;
+extern gate_desc kexec_debug_idt[];
+extern unsigned char kexec_debug_exc_vectors[];
 #endif
 
 /*
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index a68f5a0a9f37..faf2fb1cd9f6 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -304,6 +304,24 @@ static void load_segments(void)
 		);
 }
 
+static void prepare_debug_idt(unsigned long control_page, unsigned long vec_ofs)
+{
+	gate_desc idtentry = { 0 };
+	int i;
+
+	idtentry.bits.p = 1;
+	idtentry.bits.type = GATE_TRAP;
+	idtentry.segment = __KERNEL_CS;
+	idtentry.offset_low = (control_page & 0xFFFF) + vec_ofs;
+	idtentry.offset_middle = (control_page >> 16) & 0xFFFF;
+	idtentry.offset_high = control_page >> 32;
+
+	for (i = 0; i < 16; i++) {
+		kexec_debug_idt[i] = idtentry;
+		idtentry.offset_low += KEXEC_DEBUG_EXC_HANDLER_SIZE;
+	}
+}
+
 int machine_kexec_prepare(struct kimage *image)
 {
 	void *control_page = page_address(image->control_code_page);
@@ -321,6 +339,9 @@ int machine_kexec_prepare(struct kimage *image)
 	if (image->type == KEXEC_TYPE_DEFAULT)
 		kexec_pa_swap_page = page_to_pfn(image->swap_page) << PAGE_SHIFT;
 
+	prepare_debug_idt((unsigned long)__pa(control_page),
+			  (unsigned long)kexec_debug_exc_vectors - reloc_start);
+
 	__memcpy(control_page, __relocate_kernel_start, reloc_end - reloc_start);
 
 	set_memory_rox((unsigned long)control_page, 1);
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index ac058971a382..5bf3eec2821b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -50,6 +50,11 @@ SYM_DATA_START_LOCAL(kexec_debug_gdt)
 	.quad   0x00cf92000000ffff      /* __KERNEL_DS */
 SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
 
+	.balign 8
+SYM_DATA_START(kexec_debug_idt)
+	.skip 0x100, 0x00
+SYM_DATA_END(kexec_debug_idt)
+
 	.section .text..relocate_kernel,"ax";
 	.code64
 SYM_CODE_START_NOALIGN(relocate_kernel)
@@ -139,6 +144,15 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	movq	%ds, %rax
 	movq	%rax, %ds
 
+	/* Now an IDTR on the stack to load the IDT the kernel created */
+	leaq	kexec_debug_idt(%rip), %rsi
+	pushq	%rsi
+	pushw	$0xff
+	lidt	(%rsp)
+	addq	$10, %rsp
+
+	//int3
+
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
 	 * below.
@@ -364,3 +378,63 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
 	ret
 	int3
 SYM_CODE_END(swap_pages)
+
+SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
+	/* Each of these is 6 bytes. */
+.macro vec_err exc
+	UNWIND_HINT_ENTRY
+	. = kexec_debug_exc_vectors + (\exc * KEXEC_DEBUG_EXC_HANDLER_SIZE)
+	nop
+	nop
+	pushq	$\exc
+	jmp	exc_handler
+.endm
+
+.macro vec_noerr exc
+	UNWIND_HINT_ENTRY
+	. = kexec_debug_exc_vectors + (\exc * KEXEC_DEBUG_EXC_HANDLER_SIZE)
+	pushq	$0
+	pushq	$\exc
+	jmp	exc_handler
+.endm
+
+	ANNOTATE_NOENDBR
+	vec_noerr 0 // #DE
+	vec_noerr 1 // #DB
+	vec_noerr 2 // #NMI
+	vec_noerr 3 // #BP
+	vec_noerr 4 // #OF
+	vec_noerr 5 // #BR
+	vec_noerr 6 // #UD
+	vec_noerr 7 // #NM
+	vec_err 8   // #DF
+	vec_noerr 9
+	vec_err 10 // #TS
+	vec_err 11 // #NP
+	vec_err 12 // #SS
+	vec_err 13 // #GP
+	vec_err 14 // #PF
+	vec_noerr 15
+SYM_CODE_END(kexec_debug_exc_vectors)
+
+SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
+	pushq	%rax
+	pushq	%rdx
+	movw	$0x3f8, %dx
+	movb	$'A', %al
+	outb	%al, %dx
+	popq	%rdx
+	popq	%rax
+
+	/* Only return from int3 */
+	cmpq	$3, (%rsp)
+	jne	.Ldie
+
+	addq	$16, %rsp
+	iretq
+
+.Ldie:
+	hlt
+	jmp	.Ldie
+
+SYM_CODE_END(exc_handler)
-- 
2.48.1

[tip: x86/boot] x86/kexec: Add relocate_kernel() debugging support: Load an IDT and basic exception entry points

[tip-bot2 for David Woodhouse]

The following commit has been merged into the x86/boot branch of tip:

Commit-ID:     e7af930606442f838c7efeaa1bcd46020337dda8
Gitweb:        https://git.kernel.org/tip/e7af930606442f838c7efeaa1bcd46020337dda8
Author:        David Woodhouse <dwmw@amazon.co.uk>
AuthorDate:    Wed, 12 Mar 2025 14:34:14 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Mar 2025 11:23:32 +01:00

x86/kexec: Add relocate_kernel() debugging support: Load an IDT and basic exception entry points

Further extend relocate_kernel() debuggability by loading an
IDT and adding exception entry points.

[ mingo: Minor beautifying of prepare_debug_idt() ]

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250312144257.2348250-3-dwmw2@infradead.org
---
 arch/x86/include/asm/kexec.h         |  5 ++-
 arch/x86/kernel/machine_kexec_64.c   | 21 ++++++++-
 arch/x86/kernel/relocate_kernel_64.S | 74 +++++++++++++++++++++++++++-
 3 files changed, 100 insertions(+)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 8ad1874..ec7636f 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -8,6 +8,9 @@
 # define PA_PGD			2
 # define PA_SWAP_PAGE		3
 # define PAGES_NR		4
+#else
+/* Size of each exception handler referenced by the IDT */
+# define KEXEC_DEBUG_EXC_HANDLER_SIZE	6 /* pushi, pushi, 2-byte jmp */
 #endif
 
 # define KEXEC_CONTROL_PAGE_SIZE	4096
@@ -58,6 +61,8 @@ struct kimage;
 extern unsigned long kexec_va_control_page;
 extern unsigned long kexec_pa_table_page;
 extern unsigned long kexec_pa_swap_page;
+extern gate_desc kexec_debug_idt[];
+extern unsigned char kexec_debug_exc_vectors[];
 #endif
 
 /*
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index a68f5a0..cc73f97 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -304,6 +304,24 @@ static void load_segments(void)
 		);
 }
 
+static void prepare_debug_idt(unsigned long control_page, unsigned long vec_ofs)
+{
+	gate_desc idtentry = { 0 };
+	int i;
+
+	idtentry.bits.p		= 1;
+	idtentry.bits.type	= GATE_TRAP;
+	idtentry.segment	= __KERNEL_CS;
+	idtentry.offset_low	= (control_page & 0xFFFF) + vec_ofs;
+	idtentry.offset_middle	= (control_page >> 16) & 0xFFFF;
+	idtentry.offset_high	= control_page >> 32;
+
+	for (i = 0; i < 16; i++) {
+		kexec_debug_idt[i] = idtentry;
+		idtentry.offset_low += KEXEC_DEBUG_EXC_HANDLER_SIZE;
+	}
+}
+
 int machine_kexec_prepare(struct kimage *image)
 {
 	void *control_page = page_address(image->control_code_page);
@@ -321,6 +339,9 @@ int machine_kexec_prepare(struct kimage *image)
 	if (image->type == KEXEC_TYPE_DEFAULT)
 		kexec_pa_swap_page = page_to_pfn(image->swap_page) << PAGE_SHIFT;
 
+	prepare_debug_idt((unsigned long)__pa(control_page),
+			  (unsigned long)kexec_debug_exc_vectors - reloc_start);
+
 	__memcpy(control_page, __relocate_kernel_start, reloc_end - reloc_start);
 
 	set_memory_rox((unsigned long)control_page, 1);
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index ac05897..bce0cb7 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -50,6 +50,11 @@ SYM_DATA_START_LOCAL(kexec_debug_gdt)
 	.quad   0x00cf92000000ffff      /* __KERNEL_DS */
 SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
 
+	.balign 8
+SYM_DATA_START(kexec_debug_idt)
+	.skip 0x100, 0x00
+SYM_DATA_END(kexec_debug_idt)
+
 	.section .text..relocate_kernel,"ax";
 	.code64
 SYM_CODE_START_NOALIGN(relocate_kernel)
@@ -139,6 +144,15 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	movq	%ds, %rax
 	movq	%rax, %ds
 
+	/* Now an IDTR on the stack to load the IDT the kernel created */
+	leaq	kexec_debug_idt(%rip), %rsi
+	pushq	%rsi
+	pushw	$0xff
+	lidt	(%rsp)
+	addq	$10, %rsp
+
+	// int3
+
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
 	 * below.
@@ -364,3 +378,63 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
 	ret
 	int3
 SYM_CODE_END(swap_pages)
+
+SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
+	/* Each of these is 6 bytes. */
+.macro vec_err exc
+	UNWIND_HINT_ENTRY
+	. = kexec_debug_exc_vectors + (\exc * KEXEC_DEBUG_EXC_HANDLER_SIZE)
+	nop
+	nop
+	pushq	$\exc
+	jmp	exc_handler
+.endm
+
+.macro vec_noerr exc
+	UNWIND_HINT_ENTRY
+	. = kexec_debug_exc_vectors + (\exc * KEXEC_DEBUG_EXC_HANDLER_SIZE)
+	pushq	$0
+	pushq	$\exc
+	jmp	exc_handler
+.endm
+
+	ANNOTATE_NOENDBR
+	vec_noerr 0 // #DE
+	vec_noerr 1 // #DB
+	vec_noerr 2 // #NMI
+	vec_noerr 3 // #BP
+	vec_noerr 4 // #OF
+	vec_noerr 5 // #BR
+	vec_noerr 6 // #UD
+	vec_noerr 7 // #NM
+	vec_err 8   // #DF
+	vec_noerr 9
+	vec_err 10 // #TS
+	vec_err 11 // #NP
+	vec_err 12 // #SS
+	vec_err 13 // #GP
+	vec_err 14 // #PF
+	vec_noerr 15
+SYM_CODE_END(kexec_debug_exc_vectors)
+
+SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
+	pushq	%rax
+	pushq	%rdx
+	movw	$0x3f8, %dx
+	movb	$'A', %al
+	outb	%al, %dx
+	popq	%rdx
+	popq	%rax
+
+	/* Only return from int3 */
+	cmpq	$3, (%rsp)
+	jne	.Ldie
+
+	addq	$16, %rsp
+	iretq
+
+.Ldie:
+	hlt
+	jmp	.Ldie
+
+SYM_CODE_END(exc_handler)

[PATCH v7 3/8] x86/kexec: Debugging support: Dump registers on exception

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

The actual serial output function is a no-op for now.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/relocate_kernel_64.S | 101 ++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 5bf3eec2821b..2cc35ca11c3e 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -379,6 +379,69 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
 	int3
 SYM_CODE_END(swap_pages)
 
+/*
+ * Generic 'print character' routine (as yet unimplemented)
+ *  - %al: Character to be printed (may clobber %rax)
+ *  - %rdx: MMIO address or port.
+ */
+SYM_CODE_START_LOCAL_NOALIGN(pr_char)
+	UNWIND_HINT_FUNC
+	ANNOTATE_NOENDBR
+	ANNOTATE_UNRET_SAFE
+	ret
+SYM_CODE_END(pr_char)
+
+/*
+ * Load pr_char function pointer into %rsi and load %rdx with whatever
+ * that function wants to see there (typically port/MMIO address).
+ */
+.macro	pr_setup
+	/* No output; pr_char just returns */
+	leaq	pr_char(%rip), %rsi
+.endm
+
+/* Print the nybble in %bl, clobber %rax */
+SYM_CODE_START_LOCAL_NOALIGN(pr_nybble)
+	UNWIND_HINT_FUNC
+	movb	%bl, %al
+	nop
+	andb	$0x0f, %al
+	addb 	$0x30, %al
+	cmpb	$0x3a, %al
+	jb	1f
+	addb	$('a' - '0' - 10), %al
+	ANNOTATE_RETPOLINE_SAFE
+1:	jmp	*%rsi
+SYM_CODE_END(pr_nybble)
+
+SYM_CODE_START_LOCAL_NOALIGN(pr_qword)
+	UNWIND_HINT_FUNC
+	movq	$16, %rcx
+1:	rolq	$4, %rbx
+	call	pr_nybble
+	loop	1b
+	movb	$'\n', %al
+	ANNOTATE_RETPOLINE_SAFE
+	jmp	*%rsi
+SYM_CODE_END(pr_qword)
+
+.macro print_reg a, b, c, d, r
+	movb	$\a, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\b, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\c, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\d, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movq	\r, %rbx
+	call	pr_qword
+.endm
+
 SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
 	/* Each of these is 6 bytes. */
 .macro vec_err exc
@@ -419,11 +482,43 @@ SYM_CODE_END(kexec_debug_exc_vectors)
 
 SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
 	pushq	%rax
+	pushq	%rbx
+	pushq	%rcx
 	pushq	%rdx
-	movw	$0x3f8, %dx
-	movb	$'A', %al
-	outb	%al, %dx
+	pushq	%rsi
+
+	/* Set up %rdx/%rsi for debug output */
+	pr_setup
+
+	/* rip and exception info */
+	print_reg 'E', 'x', 'c', ':', 0x28(%rsp)
+	print_reg 'E', 'r', 'r', ':', 0x30(%rsp)
+	print_reg 'r', 'i', 'p', ':', 0x38(%rsp)
+	print_reg 'r', 's', 'p', ':', 0x50(%rsp)
+
+	/* We spilled these to the stack */
+	print_reg 'r', 'a', 'x', ':', 0x20(%rsp)
+	print_reg 'r', 'b', 'x', ':', 0x18(%rsp)
+	print_reg 'r', 'c', 'x', ':', 0x10(%rsp)
+	print_reg 'r', 'd', 'x', ':', 0x08(%rsp)
+
+	/* Other registers */
+	print_reg 'r', 's', 'i', ':', (%rsp)
+	print_reg 'r', 'd', 'i', ':', %rdi
+	print_reg 'r', '8', ' ', ':', %r8
+	print_reg 'r', '9', ' ', ':', %r9
+	print_reg 'r', '1', '0', ':', %r10
+	print_reg 'r', '1', '1', ':', %r11
+	print_reg 'r', '1', '2', ':', %r12
+	print_reg 'r', '1', '3', ':', %r13
+	print_reg 'r', '1', '4', ':', %r14
+	print_reg 'r', '1', '5', ':', %r15
+	print_reg 'c', 'r', '2', ':', %cr2
+
+	popq	%rsi
 	popq	%rdx
+	popq	%rcx
+	popq	%rbx
 	popq	%rax
 
 	/* Only return from int3 */
-- 
2.48.1

[tip: x86/boot] x86/kexec: Add relocate_kernel() debugging support: Dump registers on exception

[tip-bot2 for David Woodhouse]

The following commit has been merged into the x86/boot branch of tip:

Commit-ID:     d181cfc0609bcbbc1fb70dbd73f7aa9025c11b6b
Gitweb:        https://git.kernel.org/tip/d181cfc0609bcbbc1fb70dbd73f7aa9025c11b6b
Author:        David Woodhouse <dwmw@amazon.co.uk>
AuthorDate:    Wed, 12 Mar 2025 14:34:15 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Mar 2025 11:23:39 +01:00

x86/kexec: Add relocate_kernel() debugging support: Dump registers on exception

The actual serial output function is a no-op for now.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250312144257.2348250-4-dwmw2@infradead.org
---
 arch/x86/kernel/relocate_kernel_64.S | 101 +++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index bce0cb7..e0af37e 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -379,6 +379,69 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
 	int3
 SYM_CODE_END(swap_pages)
 
+/*
+ * Generic 'print character' routine (as yet unimplemented)
+ *  - %al: Character to be printed (may clobber %rax)
+ *  - %rdx: MMIO address or port.
+ */
+SYM_CODE_START_LOCAL_NOALIGN(pr_char)
+	UNWIND_HINT_FUNC
+	ANNOTATE_NOENDBR
+	ANNOTATE_UNRET_SAFE
+	ret
+SYM_CODE_END(pr_char)
+
+/*
+ * Load pr_char function pointer into %rsi and load %rdx with whatever
+ * that function wants to see there (typically port/MMIO address).
+ */
+.macro	pr_setup
+	/* No output; pr_char just returns */
+	leaq	pr_char(%rip), %rsi
+.endm
+
+/* Print the nybble in %bl, clobber %rax */
+SYM_CODE_START_LOCAL_NOALIGN(pr_nybble)
+	UNWIND_HINT_FUNC
+	movb	%bl, %al
+	nop
+	andb	$0x0f, %al
+	addb	$0x30, %al
+	cmpb	$0x3a, %al
+	jb	1f
+	addb	$('a' - '0' - 10), %al
+	ANNOTATE_RETPOLINE_SAFE
+1:	jmp	*%rsi
+SYM_CODE_END(pr_nybble)
+
+SYM_CODE_START_LOCAL_NOALIGN(pr_qword)
+	UNWIND_HINT_FUNC
+	movq	$16, %rcx
+1:	rolq	$4, %rbx
+	call	pr_nybble
+	loop	1b
+	movb	$'\n', %al
+	ANNOTATE_RETPOLINE_SAFE
+	jmp	*%rsi
+SYM_CODE_END(pr_qword)
+
+.macro print_reg a, b, c, d, r
+	movb	$\a, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\b, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\c, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movb	$\d, %al
+	ANNOTATE_RETPOLINE_SAFE
+	call	*%rsi
+	movq	\r, %rbx
+	call	pr_qword
+.endm
+
 SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
 	/* Each of these is 6 bytes. */
 .macro vec_err exc
@@ -419,11 +482,43 @@ SYM_CODE_END(kexec_debug_exc_vectors)
 
 SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
 	pushq	%rax
+	pushq	%rbx
+	pushq	%rcx
 	pushq	%rdx
-	movw	$0x3f8, %dx
-	movb	$'A', %al
-	outb	%al, %dx
+	pushq	%rsi
+
+	/* Set up %rdx/%rsi for debug output */
+	pr_setup
+
+	/* rip and exception info */
+	print_reg 'E', 'x', 'c', ':', 0x28(%rsp)
+	print_reg 'E', 'r', 'r', ':', 0x30(%rsp)
+	print_reg 'r', 'i', 'p', ':', 0x38(%rsp)
+	print_reg 'r', 's', 'p', ':', 0x50(%rsp)
+
+	/* We spilled these to the stack */
+	print_reg 'r', 'a', 'x', ':', 0x20(%rsp)
+	print_reg 'r', 'b', 'x', ':', 0x18(%rsp)
+	print_reg 'r', 'c', 'x', ':', 0x10(%rsp)
+	print_reg 'r', 'd', 'x', ':', 0x08(%rsp)
+
+	/* Other registers */
+	print_reg 'r', 's', 'i', ':', (%rsp)
+	print_reg 'r', 'd', 'i', ':', %rdi
+	print_reg 'r', '8', ' ', ':', %r8
+	print_reg 'r', '9', ' ', ':', %r9
+	print_reg 'r', '1', '0', ':', %r10
+	print_reg 'r', '1', '1', ':', %r11
+	print_reg 'r', '1', '2', ':', %r12
+	print_reg 'r', '1', '3', ':', %r13
+	print_reg 'r', '1', '4', ':', %r14
+	print_reg 'r', '1', '5', ':', %r15
+	print_reg 'c', 'r', '2', ':', %cr2
+
+	popq	%rsi
 	popq	%rdx
+	popq	%rcx
+	popq	%rbx
 	popq	%rax
 
 	/* Only return from int3 */

[PATCH v7 4/8] x86/kexec: Add 8250 serial port output

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

If a serial port was configured for early_printk, use it for debug output
from the relocate_kernel exception handler too.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/include/asm/kexec.h         |  1 +
 arch/x86/kernel/early_printk.c       |  6 +++++
 arch/x86/kernel/relocate_kernel_64.S | 39 +++++++++++++++++++++++-----
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index ec7636f4f86a..8cbdb6fd10c2 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -63,6 +63,7 @@ extern unsigned long kexec_pa_table_page;
 extern unsigned long kexec_pa_swap_page;
 extern gate_desc kexec_debug_idt[];
 extern unsigned char kexec_debug_exc_vectors[];
+extern uint16_t kexec_debug_8250_port;
 #endif
 
 /*
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 44f937015e1e..ed4e8d0218ad 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <linux/console.h>
 #include <linux/kernel.h>
+#include <linux/kexec.h>
 #include <linux/init.h>
 #include <linux/string.h>
 #include <linux/screen_info.h>
@@ -141,6 +142,11 @@ static __init void early_serial_hw_init(unsigned divisor)
 	serial_out(early_serial_base, DLL, divisor & 0xff);
 	serial_out(early_serial_base, DLH, (divisor >> 8) & 0xff);
 	serial_out(early_serial_base, LCR, c & ~DLAB);
+
+#ifdef CONFIG_KEXEC_CORE
+	if (serial_in == io_serial_in)
+		kexec_debug_8250_port = early_serial_base;
+#endif
 }
 
 #define DEFAULT_BAUD 9600
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 2cc35ca11c3e..a51b9340934b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -39,6 +39,7 @@ SYM_DATA(kexec_va_control_page, .quad 0)
 SYM_DATA(kexec_pa_table_page, .quad 0)
 SYM_DATA(kexec_pa_swap_page, .quad 0)
 SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
+SYM_DATA(kexec_debug_8250_port, .word 0)
 
 	.balign 16
 SYM_DATA_START_LOCAL(kexec_debug_gdt)
@@ -380,24 +381,50 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
 SYM_CODE_END(swap_pages)
 
 /*
- * Generic 'print character' routine (as yet unimplemented)
+ * Generic 'print character' routine
  *  - %al: Character to be printed (may clobber %rax)
  *  - %rdx: MMIO address or port.
  */
-SYM_CODE_START_LOCAL_NOALIGN(pr_char)
+#define XMTRDY          0x20
+
+#define TXR             0       /*  Transmit register (WRITE) */
+#define LSR             5       /*  Line Status               */
+
+SYM_CODE_START_LOCAL_NOALIGN(pr_char_8250)
 	UNWIND_HINT_FUNC
 	ANNOTATE_NOENDBR
+	addw	$LSR, %dx
+	xchg	%al, %ah
+.Lxmtrdy_loop:
+	inb	%dx, %al
+	testb	$XMTRDY, %al
+	jnz	.Lready
+	rep nop
+	jmp .Lxmtrdy_loop
+
+.Lready:
+	subw	$LSR, %dx
+	xchg	%al, %ah
+	outb	%al, %dx
+pr_char_null:
+	ANNOTATE_NOENDBR
+
 	ANNOTATE_UNRET_SAFE
 	ret
-SYM_CODE_END(pr_char)
+SYM_CODE_END(pr_char_8250)
 
 /*
  * Load pr_char function pointer into %rsi and load %rdx with whatever
  * that function wants to see there (typically port/MMIO address).
  */
-.macro	pr_setup
-	/* No output; pr_char just returns */
-	leaq	pr_char(%rip), %rsi
+.macro pr_setup
+	leaq	pr_char_8250(%rip), %rsi
+	movw	kexec_debug_8250_port(%rip), %dx
+	testw	%dx, %dx
+	jnz	1f
+
+	leaq	pr_char_null(%rip), %rsi
+1:
 .endm
 
 /* Print the nybble in %bl, clobber %rax */
-- 
2.48.1

Re: [PATCH v7 4/8] x86/kexec: Add 8250 serial port output

[Ingo Molnar]

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

> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> If a serial port was configured for early_printk, use it for debug output
> from the relocate_kernel exception handler too.

Does the early console output something once it's initialized? If not 
then I'd go one step further here: if early_printk serial debugging was 
configured, let's output some sort of message as early as it's expected 
to work. That way if any of this debug codepath regresses for 
relocate_kernel, the discovery of that regression won't be delayed 
until something nasty triggers within relocate_kernel that would 
necessitate a working debug mechanism ...

Also, printing something to the early console using these new 
relocate_kernel printing functions would be an additional bonus as 
well, for similar reasons.

Thanks,

	Ingo

[PATCH v7 5/8] x86/kexec: Add 8250 MMIO serial port output

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

This supports the same 32-bit MMIO-mapped 8250 as the early_printk code.

It's not clear why the early_printk code supports this form and only this
form; the actual runtime 8250_pci doesn't seem to support it. But having
hacked up QEMU to expose such a device, early_printk does work with it,
and now so does the kexec debug code.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/include/asm/kexec.h         |  1 +
 arch/x86/kernel/early_printk.c       |  3 +++
 arch/x86/kernel/machine_kexec_64.c   | 17 +++++++++++++++++
 arch/x86/kernel/relocate_kernel_64.S | 22 ++++++++++++++++++++++
 4 files changed, 43 insertions(+)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 8cbdb6fd10c2..5081d0b9e290 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -64,6 +64,7 @@ extern unsigned long kexec_pa_swap_page;
 extern gate_desc kexec_debug_idt[];
 extern unsigned char kexec_debug_exc_vectors[];
 extern uint16_t kexec_debug_8250_port;
+extern unsigned long kexec_debug_8250_mmio32;
 #endif
 
 /*
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index ed4e8d0218ad..989117b2d455 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -296,6 +296,9 @@ static __init void early_pci_serial_init(char *s)
 		/* WARNING! assuming the address is always in the first 4G */
 		early_serial_base =
 			(unsigned long)early_ioremap(bar0 & PCI_BASE_ADDRESS_MEM_MASK, 0x10);
+#ifdef CONFIG_KEXEC_CORE
+		kexec_debug_8250_mmio32 = bar0 & PCI_BASE_ADDRESS_MEM_MASK;
+#endif
 		write_pci_config(bus, slot, func, PCI_COMMAND,
 				 cmdreg|PCI_COMMAND_MEMORY);
 	}
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index faf2fb1cd9f6..a2e00a814708 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -76,6 +76,19 @@ map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p)
 static int map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) { return 0; }
 #endif
 
+static int map_mmio_serial(struct x86_mapping_info *info, pgd_t *level4p)
+{
+	unsigned long mstart, mend;
+
+	if (!kexec_debug_8250_mmio32)
+		return 0;
+
+	mstart = kexec_debug_8250_mmio32 & PAGE_MASK;
+	mend = (kexec_debug_8250_mmio32 + PAGE_SIZE + 23) & PAGE_MASK;
+	pr_info("Map PCI serial at %lx - %lx\n", mstart, mend);
+	return kernel_ident_mapping_init(info, level4p, mstart, mend);
+}
+
 #ifdef CONFIG_KEXEC_FILE
 const struct kexec_file_ops * const kexec_file_loaders[] = {
 		&kexec_bzImage64_ops,
@@ -285,6 +298,10 @@ static int init_pgtable(struct kimage *image, unsigned long control_page)
 	if (result)
 		return result;
 
+	result = map_mmio_serial(&info, image->arch.pgd);
+	if (result)
+		return result;
+
 	/*
 	 * This must be last because the intermediate page table pages it
 	 * allocates will not be control pages and may overlap the image.
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index a51b9340934b..d58b4686645c 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -39,6 +39,7 @@ SYM_DATA(kexec_va_control_page, .quad 0)
 SYM_DATA(kexec_pa_table_page, .quad 0)
 SYM_DATA(kexec_pa_swap_page, .quad 0)
 SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
+SYM_DATA(kexec_debug_8250_mmio32, .quad 0)
 SYM_DATA(kexec_debug_8250_port, .word 0)
 
 	.balign 16
@@ -413,6 +414,22 @@ pr_char_null:
 	ret
 SYM_CODE_END(pr_char_8250)
 
+SYM_CODE_START_LOCAL_NOALIGN(pr_char_8250_mmio32)
+	UNWIND_HINT_FUNC
+	ANNOTATE_NOENDBR
+.Lxmtrdy_loop_mmio:
+	movb	(LSR*4)(%rdx), %ah
+	testb	$XMTRDY, %ah
+	jnz	.Lready_mmio
+	rep nop
+	jmp .Lxmtrdy_loop_mmio
+
+.Lready_mmio:
+	movb	%al, (%rdx)
+	ANNOTATE_UNRET_SAFE
+	ret
+SYM_CODE_END(pr_char_8250_mmio32)
+
 /*
  * Load pr_char function pointer into %rsi and load %rdx with whatever
  * that function wants to see there (typically port/MMIO address).
@@ -423,6 +440,11 @@ SYM_CODE_END(pr_char_8250)
 	testw	%dx, %dx
 	jnz	1f
 
+	leaq	pr_char_8250_mmio32(%rip), %rsi
+	movq	kexec_debug_8250_mmio32(%rip), %rdx
+	testq	%rdx, %rdx
+	jnz	1f
+
 	leaq	pr_char_null(%rip), %rsi
 1:
 .endm
-- 
2.48.1

[PATCH v7 6/8] x86/kexec: Invalidate GDT/IDT from relocate_kernel() instead of earlier

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

Commit 2114796ca041 ("x86/kexec: Mark machine_kexec() with __nocfi") marked
the machine_kexec() function with __nocfi because I failed to make objtool
happy when actually *providing* CFI information for the relocate_kernel()
function that it calls, and __nocfi was the easy workaround.

When that eventually gets fixed, the check on calling the relocate_kernel()
function pointer may trap. Obviously that should never happen unless the
function prototype gets messed up, but that's exactly what the CFI check is
for.

So it would be kind of helpful if the IDT was still in place and the trap
could be *handled*. It can remain valid until the moment that %cr3 gets
replaced, so shift the invalidation down into relocate_kernel() itself.

This is a useful cleanup regardless of making CFI work, so do it now.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/machine_kexec_64.c   | 10 ++--------
 arch/x86/kernel/relocate_kernel_64.S |  9 +++++++--
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index a2e00a814708..7abc7aa0261b 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -434,16 +434,10 @@ void __nocfi machine_kexec(struct kimage *image)
 	 * with from a table in memory.  At no other time is the
 	 * descriptor table in memory accessed.
 	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
+	 * Take advantage of this here by force loading the segments,
+	 * before the GDT is zapped with an invalid value.
 	 */
 	load_segments();
-	/*
-	 * The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	native_idt_invalidate();
-	native_gdt_invalidate();
 
 	/* now call it */
 	image->start = relocate_kernel_ptr((unsigned long)image->head,
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index d58b4686645c..17d41e6e1a4b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -79,8 +79,13 @@ SYM_CODE_START_NOALIGN(relocate_kernel)
 	pushq %r15
 	pushf
 
-	/* zero out flags, and disable interrupts */
-	pushq $0
+	/* Invalidate GDT/IDT, zero out flags */
+	pushq	$0
+	pushq	$0
+
+	lidt	(%rsp)
+	lgdt	(%rsp)
+	addq	$8, %rsp
 	popfq
 
 	/* Switch to the identity mapped page tables */
-- 
2.48.1

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

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/relocate_kernel_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 17d41e6e1a4b..2b7fc59af373 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -158,7 +158,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
 	lidt	(%rsp)
 	addq	$10, %rsp
 
-	//int3
+	int3
 
 	/*
 	 * Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
-- 
2.48.1

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

[Ingo Molnar]

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

> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
>  arch/x86/kernel/relocate_kernel_64.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
> index 17d41e6e1a4b..2b7fc59af373 100644
> --- a/arch/x86/kernel/relocate_kernel_64.S
> +++ b/arch/x86/kernel/relocate_kernel_64.S
> @@ -158,7 +158,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
>  	lidt	(%rsp)
>  	addq	$10, %rsp
>  
> -	//int3
> +	int3

So this is all boot-serialized functionality with no SMP concerns 
whatsoever, right?

If yes then we could use something like this:

	static int exception_selftest = 1;

and add the INT3 point:

	int3
.globl after_int3
after_int3:

And do this in the early exception handler:

	...
	
	if (exception_selftest) {
		exception_selftest = 0;

		print_something_warm_and_fuzzy();

		IRET-to-after_int3;
	}

	...

	... regular exception path ...

... but all in assembly or so ;-)

This would make it reasonably certain that the most complex bits of 
this new debuging code are in working order, all the time.

Thanks,

	Ingo

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

[David Woodhouse]

On 13 March 2025 11:44:41 CET, Ingo Molnar <mingo@kernel.org> wrote:
>
>* David Woodhouse <dwmw2@infradead.org> wrote:
>
>> From: David Woodhouse <dwmw@amazon.co.uk>
>> 
>> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>> ---
>>  arch/x86/kernel/relocate_kernel_64.S | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
>> index 17d41e6e1a4b..2b7fc59af373 100644
>> --- a/arch/x86/kernel/relocate_kernel_64.S
>> +++ b/arch/x86/kernel/relocate_kernel_64.S
>> @@ -158,7 +158,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
>>  	lidt	(%rsp)
>>  	addq	$10, %rsp
>>  
>> -	//int3
>> +	int3
>
>So this is all boot-serialized functionality with no SMP concerns 
>whatsoever, right?
>
>If yes then we could use something like this:
>
>	static int exception_selftest = 1;
>
>and add the INT3 point:
>
>	int3
>.globl after_int3
>after_int3:
>
>And do this in the early exception handler:
>
>	...
>	
>	if (exception_selftest) {
>		exception_selftest = 0;
>
>		print_something_warm_and_fuzzy();
>
>		IRET-to-after_int3;
>	}
>
>	...
>
>	... regular exception path ...
>
>... but all in assembly or so ;-)
>
>This would make it reasonably certain that the most complex bits of 
>this new debuging code are in working order, all the time.
>
>Thanks,
>
>	Ingo

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.

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

[Ingo Molnar]

* David Woodhouse <dwmw2@infradead.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

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

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


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

[PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

From: David Woodhouse <dwmw@amazon.co.uk>

A previous commit added __nocfi to machine_kexec() because it makes an
indirect call to relocate_kernel() which lacked CFI type information,
and caused the system to crash.

Use SYM_TYPED_FUNC_START() to ensure that the type information is
present, and remove the __nocfi tag.

I still can't make objtool happy with this in both GCC and Clang builds
at the same time, so not yet for merging; only included in this series
to nerd-snipe the objtool maintainers.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/machine_kexec_64.c   | 2 +-
 arch/x86/kernel/relocate_kernel_64.S | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 7abc7aa0261b..84f59f18dcb6 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -380,7 +380,7 @@ void machine_kexec_cleanup(struct kimage *image)
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-void __nocfi machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long reloc_start = (unsigned long)__relocate_kernel_start;
 	relocate_kernel_fn *relocate_kernel_ptr;
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 2b7fc59af373..999aca909803 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -5,6 +5,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <linux/stringify.h>
 #include <asm/alternative.h>
 #include <asm/page_types.h>
@@ -59,8 +60,9 @@ SYM_DATA_END(kexec_debug_idt)
 
 	.section .text..relocate_kernel,"ax";
 	.code64
-SYM_CODE_START_NOALIGN(relocate_kernel)
+SYM_TYPED_FUNC_START(relocate_kernel)
 	UNWIND_HINT_END_OF_STACK
+	UNWIND_HINT_FUNC
 	ANNOTATE_NOENDBR
 	/*
 	 * %rdi indirection_page
-- 
2.48.1

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Wed, Mar 12, 2025 at 02:34:20PM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> A previous commit added __nocfi to machine_kexec() because it makes an
> indirect call to relocate_kernel() which lacked CFI type information,
> and caused the system to crash.
> 
> Use SYM_TYPED_FUNC_START() to ensure that the type information is
> present, and remove the __nocfi tag.
> 
> I still can't make objtool happy with this in both GCC and Clang builds
> at the same time, so not yet for merging; only included in this series
> to nerd-snipe the objtool maintainers.

Again, I'd recommend just compiling the code in .data..relocate_kernel.
Then objtool doesn't need to care.

Otherwise it would help to know what warnings you're getting with this
patch, and the corresponding .config.

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Fri, 2025-03-14 at 09:07 -0700, Josh Poimboeuf wrote:
> On Wed, Mar 12, 2025 at 02:34:20PM +0000, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > A previous commit added __nocfi to machine_kexec() because it makes an
> > indirect call to relocate_kernel() which lacked CFI type information,
> > and caused the system to crash.
> > 
> > Use SYM_TYPED_FUNC_START() to ensure that the type information is
> > present, and remove the __nocfi tag.
> > 
> > I still can't make objtool happy with this in both GCC and Clang builds
> > at the same time, so not yet for merging; only included in this series
> > to nerd-snipe the objtool maintainers.
> 
> Again, I'd recommend just compiling the code in .data..relocate_kernel.
> Then objtool doesn't need to care.
> 
> Otherwise it would help to know what warnings you're getting with this
> patch, and the corresponding .config.

ISTR this version is OK with Clang and CONFIG_CFI_CLANG but with GCC I
get this:

vmlinux.o: warning: objtool: relocate_kernel+0x69: unsupported stack register modification

        /* setup a new stack at the end of the physical control page */
        lea     PAGE_SIZE(%rsi), %rsp
  79:   48 8d a6 00 10 00 00    lea    0x1000(%rsi),%rsp


Maybe the answer is to put the UNWIND_HINT_FUNC into #ifdef
CONFIG_CFI_CLANG but that seems wrong.

I'll have another look at putting it in the data section, and see if I
can remember why I didn't want to do that before (and if that's still
relevant now).


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Fri, Mar 14, 2025 at 05:23:15PM +0000, David Woodhouse wrote:
> ISTR this version is OK with Clang and CONFIG_CFI_CLANG but with GCC I
> get this:
> 
> vmlinux.o: warning: objtool: relocate_kernel+0x69: unsupported stack register modification
> 
>         /* setup a new stack at the end of the physical control page */
>         lea     PAGE_SIZE(%rsi), %rsp
>   79:   48 8d a6 00 10 00 00    lea    0x1000(%rsi),%rsp
> 
> 
> Maybe the answer is to put the UNWIND_HINT_FUNC into #ifdef
> CONFIG_CFI_CLANG but that seems wrong.

The UNWIND_HINT_FUNC definitely looks wrong, why would Clang need it?

> I'll have another look at putting it in the data section, and see if I
> can remember why I didn't want to do that before (and if that's still
> relevant now).

IIRC, the reasons were the patched alternative, and also you wanted to
disassemble (but note that's still possible with gdb).

Here was a patch to make it work:

  https://lore.kernel.org/20241218212326.44qff3i5n6cxuu5d@jpoimboe

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Fri, 2025-03-14 at 10:52 -0700, Josh Poimboeuf wrote:
> On Fri, Mar 14, 2025 at 05:23:15PM +0000, David Woodhouse wrote:
> > ISTR this version is OK with Clang and CONFIG_CFI_CLANG but with GCC I
> > get this:
> > 
> > vmlinux.o: warning: objtool: relocate_kernel+0x69: unsupported stack register modification
> > 
> >         /* setup a new stack at the end of the physical control page */
> >         lea     PAGE_SIZE(%rsi), %rsp
> >   79:   48 8d a6 00 10 00 00    lea    0x1000(%rsi),%rsp
> > 
> > 
> > Maybe the answer is to put the UNWIND_HINT_FUNC into #ifdef
> > CONFIG_CFI_CLANG but that seems wrong.
> 
> The UNWIND_HINT_FUNC definitely looks wrong, why would Clang need it?

I think it's when CONFIG_CFI_CLANG makes the SYM_TYPED_FUNC_START()
macro actually emit the CFI prologue? 

> > I'll have another look at putting it in the data section, and see if I
> > can remember why I didn't want to do that before (and if that's still
> > relevant now).
> 
> IIRC, the reasons were the patched alternative, and also you wanted to
> disassemble (but note that's still possible with gdb).
> 
> Here was a patch to make it work:
> 
>   https://lore.kernel.org/20241218212326.44qff3i5n6cxuu5d@jpoimboe

Yeah, that does seem reasonable. Sorry, I think I missed that before
Christmas. I'll look at rolling it in. This part is kind of orthogonal
to the actual debug support so it's fine to keep it separate.

Thanks.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

On Fri, 2025-03-14 at 10:52 -0700, Josh Poimboeuf wrote:
> 
> IIRC, the reasons were the patched alternative, and also you wanted to
> disassemble (but note that's still possible with gdb).

It's meaningful output from 'objdump -S' that I miss. But OK.

> Here was a patch to make it work:
> 
>   https://lore.kernel.org/20241218212326.44qff3i5n6cxuu5d@jpoimboe

I've reworked that and the CR4 filtering, and now it doesn't like me
using SYM_TYPED_FUNC_START() to add the CFI information for the
relocate_kernel() function.

  LD      vmlinux.o
vmlinux.o: warning: objtool: bad call to elf_init_reloc_text_sym() for
data symbol .data..relocate_kernel
 ...

  SORTTAB vmlinux
incomplete ORC unwind tables in file: vmlinux
Failed to sort kernel tables

This happens when I build with (clang and) CONFIG_CFI_CLANG, with and
updated version of your patch above, and this on top of it. This is at
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/kexec-debug

From 0f08a44613764e9b38a1c3332812685b61c99c2e Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Mon, 16 Dec 2024 10:26:24 +0000
Subject: [PATCH] x86/kexec: Add CFI type information to relocate_kernel()

A previous commit added __nocfi to machine_kexec() because it makes an
indirect call to relocate_kernel() which lacked CFI type information,
and caused the system to crash.

Use SYM_TYPED_FUNC_START() to ensure that the type information is
present, and remove the __nocfi tag.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/machine_kexec_64.c   | 2 +-
 arch/x86/kernel/relocate_kernel_64.S | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 016862d2b544..e1f5fc858aee 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -396,7 +396,7 @@ void machine_kexec_cleanup(struct kimage *image)
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-void __nocfi machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long reloc_start = (unsigned long)__relocate_kernel_start;
 	relocate_kernel_fn *relocate_kernel_ptr;
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 814af7fa6318..c859fbe507e8 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -5,6 +5,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <linux/stringify.h>
 #include <asm/alternative.h>
 #include <asm/page_types.h>
@@ -68,7 +69,7 @@ SYM_DATA_END(kexec_debug_idt)
  * opinions about it.
  */
 	.code64
-SYM_CODE_START_NOALIGN(relocate_kernel)
+SYM_TYPED_FUNC_START(relocate_kernel)
 	/*
 	 * %rdi indirection_page
 	 * %rsi pa_control_page
-- 
2.48.1


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Mon, Mar 17, 2025 at 12:40:14PM +0000, David Woodhouse wrote:
> On Fri, 2025-03-14 at 10:52 -0700, Josh Poimboeuf wrote:
> > 
> > IIRC, the reasons were the patched alternative, and also you wanted to
> > disassemble (but note that's still possible with gdb).
> 
> It's meaningful output from 'objdump -S' that I miss. But OK.

FYI, this works:

  objdump -Srw -j .data..relocate_kernel vmlinux.o

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Mon, Mar 17, 2025 at 05:17:24PM -0700, Josh Poimboeuf wrote:
> On Mon, Mar 17, 2025 at 12:40:14PM +0000, David Woodhouse wrote:
> > On Fri, 2025-03-14 at 10:52 -0700, Josh Poimboeuf wrote:
> > > 
> > > IIRC, the reasons were the patched alternative, and also you wanted to
> > > disassemble (but note that's still possible with gdb).
> > 
> > It's meaningful output from 'objdump -S' that I miss. But OK.
> 
> FYI, this works:
> 
>   objdump -Srw -j .data..relocate_kernel vmlinux.o

... but I see now that it doesn't intersperse the source.  Never mind...

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 5762 bytes --]

On Mon, 2025-03-17 at 17:24 -0700, Josh Poimboeuf wrote:
> On Mon, Mar 17, 2025 at 05:17:24PM -0700, Josh Poimboeuf wrote:
> > On Mon, Mar 17, 2025 at 12:40:14PM +0000, David Woodhouse wrote:
> > > On Fri, 2025-03-14 at 10:52 -0700, Josh Poimboeuf wrote:
> > > > 
> > > > IIRC, the reasons were the patched alternative, and also you
> > > > wanted to
> > > > disassemble (but note that's still possible with gdb).
> > > 
> > > It's meaningful output from 'objdump -S' that I miss. But OK.
> > 
> > FYI, this works:
> > 
> >   objdump -Srw -j .data..relocate_kernel vmlinux.o
> 
> ... but I see now that it doesn't intersperse the source.  Never
> mind...

To be fair, the source is assembler. So it isn't *so* hard to work it
out.

But on the whole, I'm not sure the CFI check is worth it.

CFI checks that the caller and callee agree about the prototype of the
function being called. There are two main benefits of this:

 • to protect against attacks where function pointers are substituted
   for gadgets.

 • to protect against genuine bugs, where the caller and the callee
   disagree about the function arguments.

For the relocate_kernel() case I don't think we care much about the
first. Without a CFI prologue, no *other* code can be tricked into
calling relocate_kernel() — and besides, it's in the kernel's data
section and isn't executable anyway until the kexec code copies it to a
page that *is*. And the kexec code itself isn't just following an
arbitrary function pointer; it copies the code into the control page
and invokes it there, so it's unlikely to follow a bogus pointer
either.

It's the *second* benefit which is more relevant to us, ensuring that
the caller and the callee genuinely do agree about the prototype.

But using the SYM_TYPED_FUNC_START() macro doesn't give us that; the
CFI prologue of the asm function is just using the signature emitted by
the *caller* in the weak __kcfi_typeid_relocate_kernel symbol anyway,
so they're never going to disagree. And how *could* the assembler side
build a typeid signature from the asm anyway?

I suspect that just leaving it marked __nocfi is probably the easier
option, unless I can *hardcode* the function signature 0x19835999 in
the CFI prologue in relocate_kernel_64.S to protect against someone
accidentally changing the C-visible 'relocate_kernel_fn' typedef
without changing the corresponding assembler? But honestly, is that
likely?

Looks like this (with your objtool relaxation on top, as well as
removing load_segments() in machine_kexec_64.c if I want the check to
actually emit the warning correctly.).

I just don't think it's worth it...

From 1bbed9c611fd286b68e2c459320910c4fefd4a22 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Mon, 16 Dec 2024 10:26:24 +0000
Subject: [PATCH] x86/kexec: Add CFI type information to relocate_kernel()

A previous commit added __nocfi to machine_kexec() because it makes an
indirect call to relocate_kernel() which lacked CFI type information,
and caused the system to crash.

Use SYM_TYPED_FUNC_START() to ensure that the type information is
present, and remove the __nocfi tag. And emit the *actual* type
signature (0x19835999) because by default, asm code uses the type
signature emitted by the *caller*, which is never going to differ!

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kernel/machine_kexec_64.c   |  2 +-
 arch/x86/kernel/relocate_kernel_64.S | 19 ++++++++++++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 016862d2b544..e1f5fc858aee 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -396,7 +396,7 @@ void machine_kexec_cleanup(struct kimage *image)
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-void __nocfi machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long reloc_start = (unsigned long)__relocate_kernel_start;
 	relocate_kernel_fn *relocate_kernel_ptr;
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
index 814af7fa6318..428401e55d29 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -5,6 +5,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <linux/stringify.h>
 #include <asm/alternative.h>
 #include <asm/page_types.h>
@@ -67,8 +68,24 @@ SYM_DATA_END(kexec_debug_idt)
  * a data section even of the object file, to prevent objtool from having
  * opinions about it.
  */
+
+#ifdef CONFIG_CFI_CLANG
+/*
+ * The SYM_TYPED_FUNC_START macro emits a CFI prologue for the function,
+ * referencing the __kcfi_typeid_##name symbol which is the signature of
+ * the function prototype. The value of that symbol ends up coming from
+ * a weak symbol emitted by the *caller* (in this case machine_kexec()),
+ * which means it's *entirely* useless for checking that the caller and
+ * callee agree about the prototype of the (asm) function being called.
+ * So, we define the signature *here* for ourselves, and if the C code
+ * ever calls relocate_kernel() in the belief that it has a different
+ * prototype, then the CFI check will trigger as $DEITY intended.
+ */
+	.weak __kcfi_typeid_relocate_kernel
+	.set  __kcfi_typeid_relocate_kernel, 0x19835999
+#endif
 	.code64
-SYM_CODE_START_NOALIGN(relocate_kernel)
+SYM_TYPED_FUNC_START(relocate_kernel)
 	/*
 	 * %rdi indirection_page
 	 * %rsi pa_control_page
-- 
2.48.1



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
> But on the whole, I'm not sure the CFI check is worth it.
> 
> CFI checks that the caller and callee agree about the prototype of the
> function being called. There are two main benefits of this:
> 
>  • to protect against attacks where function pointers are substituted
>    for gadgets.
> 
>  • to protect against genuine bugs, where the caller and the callee
>    disagree about the function arguments.

AFAIK the first one is the main point of CFI.

> For the relocate_kernel() case I don't think we care much about the
> first. Without a CFI prologue, no *other* code can be tricked into
> calling relocate_kernel()

But for FineIBT the hash is checked on the callee side.  So it loses
FineIBT protection.

> — and besides, it's in the kernel's data
> section and isn't executable anyway until the kexec code copies it to a
> page that *is*.

Does the code get copied immediately before getting called, or can it be
initialized earlier during boot when kdump does its initial setup?

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

On Tue, 2025-03-18 at 10:14 -0700, Josh Poimboeuf wrote:
> On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
> > But on the whole, I'm not sure the CFI check is worth it.
> > 
> > CFI checks that the caller and callee agree about the prototype of the
> > function being called. There are two main benefits of this:
> > 
> >  • to protect against attacks where function pointers are substituted
> >    for gadgets.
> > 
> >  • to protect against genuine bugs, where the caller and the callee
> >    disagree about the function arguments.
> 
> AFAIK the first one is the main point of CFI.

In the general case yes. I just don't think it matters much for
relocate_kernel().

> > For the relocate_kernel() case I don't think we care much about the
> > first. Without a CFI prologue, no *other* code can be tricked into
> > calling relocate_kernel()
> 
> But for FineIBT the hash is checked on the callee side.  So it loses
> FineIBT protection.

Right now the relocate_kernel() code doesn't even have an endbr, does
it? So it isn't a useful gadget?

> > — and besides, it's in the kernel's data
> > section and isn't executable anyway until the kexec code copies it to a
> > page that *is*.
> 
> Does the code get copied immediately before getting called, or can it be
> initialized earlier during boot when kdump does its initial setup?

It's initialized earlier, in machine_kexec_prepare(), and then the page
is set ROX.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Tue, Mar 18, 2025 at 09:06:58PM +0000, David Woodhouse wrote:
> On Tue, 2025-03-18 at 10:14 -0700, Josh Poimboeuf wrote:
> > On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
> > > For the relocate_kernel() case I don't think we care much about the
> > > first. Without a CFI prologue, no *other* code can be tricked into
> > > calling relocate_kernel()
> > 
> > But for FineIBT the hash is checked on the callee side.  So it loses
> > FineIBT protection.
> 
> Right now the relocate_kernel() code doesn't even have an endbr, does
> it? So it isn't a useful gadget?

In that case wouldn't IBT explode when you indirect call it?  Or is IBT
getting disabled beforehand?

> > > — and besides, it's in the kernel's data
> > > section and isn't executable anyway until the kexec code copies it to a
> > > page that *is*.
> > 
> > Does the code get copied immediately before getting called, or can it be
> > initialized earlier during boot when kdump does its initial setup?
> 
> It's initialized earlier, in machine_kexec_prepare(), and then the page
> is set ROX.

If that happens during boot (like for kdump init) then it'll be in text
the whole time after boot, right?

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

On 18 March 2025 22:41:43 GMT, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>On Tue, Mar 18, 2025 at 09:06:58PM +0000, David Woodhouse wrote:
>> On Tue, 2025-03-18 at 10:14 -0700, Josh Poimboeuf wrote:
>> > On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
>> > > For the relocate_kernel() case I don't think we care much about the
>> > > first. Without a CFI prologue, no *other* code can be tricked into
>> > > calling relocate_kernel()
>> > 
>> > But for FineIBT the hash is checked on the callee side.  So it loses
>> > FineIBT protection.
>> 
>> Right now the relocate_kernel() code doesn't even have an endbr, does
>> it? So it isn't a useful gadget?
>
>In that case wouldn't IBT explode when you indirect call it?  Or is IBT
>getting disabled beforehand?

Not sure of the details. The machine_kexec() function which is the *caller* is currently marked with the __nocfi tag which stops any software checks. I guess any hardware feature which requires an endbr to be the target of an indirect branch has to already disabled on the way down? What specifically am I looking for, to check that? Or the hardware support has just never worked with kexec, perhaps?

>> > > — and besides, it's in the kernel's data
>> > > section and isn't executable anyway until the kexec code copies it to a
>> > > page that *is*.
>> > 
>> > Does the code get copied immediately before getting called, or can it be
>> > initialized earlier during boot when kdump does its initial setup?
>> 
>> It's initialized earlier, in machine_kexec_prepare(), and then the page
>> is set ROX.
>
>If that happens during boot (like for kdump init) then it'll be in text
>the whole time after boot, right?

In an executable page, yes.

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Wed, Mar 19, 2025 at 01:04:20PM +0000, David Woodhouse wrote:
> On 18 March 2025 22:41:43 GMT, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >On Tue, Mar 18, 2025 at 09:06:58PM +0000, David Woodhouse wrote:
> >> On Tue, 2025-03-18 at 10:14 -0700, Josh Poimboeuf wrote:
> >> > On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
> >> > > For the relocate_kernel() case I don't think we care much about the
> >> > > first. Without a CFI prologue, no *other* code can be tricked into
> >> > > calling relocate_kernel()
> >> > 
> >> > But for FineIBT the hash is checked on the callee side.  So it loses
> >> > FineIBT protection.
> >> 
> >> Right now the relocate_kernel() code doesn't even have an endbr, does
> >> it? So it isn't a useful gadget?
> >
> >In that case wouldn't IBT explode when you indirect call it?  Or is IBT
> >getting disabled beforehand?
> 
> Not sure of the details. The machine_kexec() function which is the
> *caller* is currently marked with the __nocfi tag which stops any
> software checks. I guess any hardware feature which requires an endbr
> to be the target of an indirect branch has to already disabled on the
> way down? What specifically am I looking for, to check that? Or the
> hardware support has just never worked with kexec, perhaps?

Looking at machine_kexec(), it calls cet_disable() before the indirect
call.  So yeah, it seems fine for relocate_kernel() to not have a CFI
prologue or ENDBR.

-- 
Josh

Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Wed, 2025-03-19 at 08:47 -0700, Josh Poimboeuf wrote:
> 
> Looking at machine_kexec(), it calls cet_disable() before the indirect
> call.  So yeah, it seems fine for relocate_kernel() to not have a CFI
> prologue or ENDBR.

Yeah. I'm just going to throw that into a branch and forget it for now.
It's just causing noise around the *actual* stuff we want to get in, to
do the exception handling.

For that, I think the only thing outstanding is to add a userspace test
based on http://david.woodhou.se/loadret.c which invokes the int3 from
the 'payload' to test it. I think this is better than doing it inside
the kernel itself, as it gives us a selftest for the kexec jump
mechanism too.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[Ingo Molnar]

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

> Debugging kexec failures is painful, as anything going wrong in execution
> of the critical relocate_kernel() function tends to just lead to a triple
> fault. Thus leading to *weeks* of my life that I won't get back. Having
> hacked something up for my own use, I figured I should share it...
> 
> Add a trivial exception handler in the relocate_kernel environment which 
> outputs to the early_printk serial console if configured. Currently only 
> 8250-compatible serial ports are supported, but that could be extended.
> 
> I had to hack up QEMU support for a PCI serial port which matches what
> the existing early_printk code can drive, and the *real* 8250_pci driver
> doesn't seem to cope with that setup at all, but whatever... the kexec
> code now drives the same 32-bit stride which is all that earlyprintk
> supports. We can always add more later, if anyone cares.
> 
> Someone who cares might want to bring the i386 version into line with
> this, although the lack of rip-based addressing makes all the PIC code a
> bit harder.
> 
> David Woodhouse (8):
>       x86/kexec: Debugging support: load a GDT
>       x86/kexec: Debugging support: Load an IDT and basic exception entry points
>       x86/kexec: Debugging support: Dump registers on exception
>       x86/kexec: Add 8250 serial port output
>       x86/kexec: Add 8250 MMIO serial port output
>       x86/kexec: Invalidate GDT/IDT from relocate_kernel() instead of earlier
>       [DO NOT MERGE] x86/kexec: Add int3 in kexec path for testing
>       [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()
> 
>  arch/x86/include/asm/kexec.h         |   7 ++
>  arch/x86/kernel/early_printk.c       |   9 ++
>  arch/x86/kernel/machine_kexec_64.c   |  50 ++++++--
>  arch/x86/kernel/relocate_kernel_64.S | 254 +++++++++++++++++++++++++++++++++++++++-
>  4 files changed, 308 insertions(+), 12 deletions(-)

I applied the first 3 patches to tip:x86/boot for phased-risk-reduction 
reasons, and because I had some questions and suggestions starting at 
patch #4.

Thanks,

	Ingo

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> I applied the first 3 patches to tip:x86/boot for 
> phased-risk-reduction reasons, and because I had some questions and 
> suggestions starting at patch #4.

So there's a new objtool build warning from the new exc_handler code:

 vmlinux.o: warning: objtool: exc_handler+0xe: early indirect call

That's with a x86-64 defconfig + KVM enablement.

Thanks,

	Ingo

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Thu, 2025-03-13 at 11:54 +0100, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@kernel.org> wrote:
> 
> > I applied the first 3 patches to tip:x86/boot for 
> > phased-risk-reduction reasons, and because I had some questions and
> > suggestions starting at patch #4.
> 
> So there's a new objtool build warning from the new exc_handler code:
> 
>  vmlinux.o: warning: objtool: exc_handler+0xe: early indirect call
> 
> That's with a x86-64 defconfig + KVM enablement.

Reproduced that by going back to x86-64 defconfig. 

vmlinux.o: warning: objtool: exc_handler+0xe: early indirect call

SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
        pushq   %rax
 2b6:   50                      push   %rax
        pushq   %rbx
 2b7:   53                      push   %rbx
        pushq   %rcx
 2b8:   51                      push   %rcx
        pushq   %rdx
 2b9:   52                      push   %rdx
        pushq   %rsi
 2ba:   56                      push   %rsi

        /* Set up %rdx/%rsi for debug output */
        pr_setup
 2bb:   48 8d 35 6e ff ff ff    lea    -0x92(%rip),%rsi        # 230 <pr_char>

        /* rip and exception info */
        print_reg 'E', 'x', 'c', ':', 0x28(%rsp)
 2c2:   b0 45                   mov    $0x45,%al
 2c4:   ff d6                   call   *%rsi



So it's the 'call *$rsi' instruction at 0x2c4, but that's annotated
with ANNOTATE_RETPOLINE_SAFE:

.macro print_reg a, b, c, d, r
	movb	$\a, %al
	ANNOTATE_RETPOLINE_SAFE
	call	*%rsi

So what's wrong with that? What *more* do I have to tell objtool to
make it shut up and go away?

Am I missing some documentation which would tell me what it's actually
unhappy about? Because "early indirect call" doesn't enlighten me very
much, and reading tools/objtool/check.c doesn't either.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Thu, 2025-03-13 at 19:58 +0000, David Woodhouse wrote:
> 
> Reproduced that by going back to x86-64 defconfig. 

Turns out the unret check doesn't even run unless CONFIG_DEBUG_ENTRY is
enabled (which enables CONFIG_NOINSTR_VALIDATION and thus runs objtool
on vmlinux.o). Which is why I didn't see it.

> vmlinux.o: warning: objtool: exc_handler+0xe: early indirect call

With Peter's help (thanks), this is fixed by adding VALIDATE_UNRET_END.
I'll squash this into the next posting:

--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -481,6 +481,9 @@ SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
 SYM_CODE_END(kexec_debug_exc_vectors)
 
 SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
+       /* No need for ret mitigations during kexec */
+       VALIDATE_UNRET_END
+
        pushq   %rax
        pushq   %rbx
        pushq   %rcx




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[Ingo Molnar]

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

> On Thu, 2025-03-13 at 19:58 +0000, David Woodhouse wrote:
> > 
> > Reproduced that by going back to x86-64 defconfig. 
> 
> Turns out the unret check doesn't even run unless CONFIG_DEBUG_ENTRY is
> enabled (which enables CONFIG_NOINSTR_VALIDATION and thus runs objtool
> on vmlinux.o). Which is why I didn't see it.
> 
> > vmlinux.o: warning: objtool: exc_handler+0xe: early indirect call
> 
> With Peter's help (thanks), this is fixed by adding VALIDATE_UNRET_END.
> I'll squash this into the next posting:
> 
> --- a/arch/x86/kernel/relocate_kernel_64.S
> +++ b/arch/x86/kernel/relocate_kernel_64.S
> @@ -481,6 +481,9 @@ SYM_CODE_START_NOALIGN(kexec_debug_exc_vectors)
>  SYM_CODE_END(kexec_debug_exc_vectors)
>  
>  SYM_CODE_START_LOCAL_NOALIGN(exc_handler)
> +       /* No need for ret mitigations during kexec */
> +       VALIDATE_UNRET_END
> +
>         pushq   %rax
>         pushq   %rbx
>         pushq   %rcx

Great!

I've applied patch #1 back to tip:x86/boot.

I've skipped the -v7 versions of patch #2 and #3 because AFAICS you've 
changed exc_handler already, so a backmerge of this annotation fix 
wouldn't be enough.

Thanks,

	Ingo

Re: [PATCH v7 0/8] x86/kexec: Add exception handling for relocate_kernel

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Fri, 2025-03-14 at 11:21 +0100, Ingo Molnar wrote:
> 
> I've applied patch #1 back to tip:x86/boot.
> 
> I've skipped the -v7 versions of patch #2 and #3 because AFAICS you've 
> changed exc_handler already, so a backmerge of this annotation fix 
> wouldn't be enough.

I haven't (yet) changed exc_handler, but I did post that annotation fix
as a patch against patch 3 in the series, when actually it should be
applied as as fixup to patch 2.

I *am* cleaning up exc_handler in patch 3 though, for a more 'warm and
fuzzy' experience on int3 rather than dumping the full register set. So
I'll repost it from patch 2 against the new tip/x86/boot, including the
annotation fix in the right place.

Thanks.

I haven't yet decided what to do about the unconditional int3. Slightly
tempted to suggest we put it in #ifdef CONFIG_DEBUG_ENTRY now I've been
reminded that option exists? But we should *also* be doing better
testing of kexec-jump, with something like that test case I posted, and
adding an int3 into that would be trivial too.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]