[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <174194741889.14745.5868283555442287108.tip-bot2@tip-bot2>
Date: Fri, 14 Mar 2025 10:16:57 -0000
From: "tip-bot2 for David Woodhouse" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: David Woodhouse <dwmw@...zon.co.uk>, Ingo Molnar <mingo@...nel.org>,
Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>,
Ard Biesheuvel <ardb@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: [tip: x86/boot] x86/kexec: Add relocate_kernel() debugging support:
Load a GDT
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@...zon.co.uk>
AuthorDate: Wed, 12 Mar 2025 14:34:13
Committer: Ingo Molnar <mingo@...nel.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@...zon.co.uk>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Brian Gerst <brgerst@...il.com>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Kees Cook <keescook@...omium.org>
Cc: Ard Biesheuvel <ardb@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-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.
Powered by blists - more mailing lists