2019-06-03 07:44:46 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2005-06-25 14:58:02 -07:00
|
|
|
/*
|
|
|
|
|
* relocate_kernel.S - put the kernel image in place to boot
|
|
|
|
|
* Copyright (C) 2002-2005 Eric Biederman <ebiederm@xmission.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/linkage.h>
|
2024-06-14 12:58:51 +03:00
|
|
|
#include <linux/stringify.h>
|
|
|
|
|
#include <asm/alternative.h>
|
2009-02-13 11:14:01 -08:00
|
|
|
#include <asm/page_types.h>
|
2006-09-26 10:52:38 +02:00
|
|
|
#include <asm/kexec.h>
|
2008-03-23 00:00:08 +03:00
|
|
|
#include <asm/processor-flags.h>
|
2009-02-13 11:14:01 -08:00
|
|
|
#include <asm/pgtable_types.h>
|
2020-03-24 15:35:42 +01:00
|
|
|
#include <asm/nospec-branch.h>
|
|
|
|
|
#include <asm/unwind_hints.h>
|
2024-12-09 08:53:32 +09:00
|
|
|
#include <asm/asm-offsets.h>
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2006-09-26 10:52:38 +02:00
|
|
|
/*
|
2022-07-08 19:10:11 +02:00
|
|
|
* Must be relocatable PIC code callable as a C function, in particular
|
|
|
|
|
* there must be a plain RET and not jump to return thunk.
|
2006-09-26 10:52:38 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define PTR(x) (x << 3)
|
2008-03-23 00:00:09 +03:00
|
|
|
#define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
|
2006-09-26 10:52:38 +02:00
|
|
|
|
2009-03-10 10:57:16 +08:00
|
|
|
/*
|
2025-01-09 14:04:17 +00:00
|
|
|
* The .text..relocate_kernel and .data..relocate_kernel sections are copied
|
2024-12-05 15:05:15 +00:00
|
|
|
* into the control page, and the remainder of the page is used as the stack.
|
2009-03-10 10:57:16 +08:00
|
|
|
*/
|
|
|
|
|
|
2025-01-09 14:04:17 +00:00
|
|
|
.section .data..relocate_kernel,"a";
|
2009-03-10 10:57:16 +08:00
|
|
|
/* Minimal CPU state */
|
2024-12-05 15:05:15 +00:00
|
|
|
SYM_DATA_LOCAL(saved_rsp, .quad 0)
|
|
|
|
|
SYM_DATA_LOCAL(saved_cr0, .quad 0)
|
|
|
|
|
SYM_DATA_LOCAL(saved_cr3, .quad 0)
|
|
|
|
|
SYM_DATA_LOCAL(saved_cr4, .quad 0)
|
|
|
|
|
/* other data */
|
2024-12-05 15:05:16 +00:00
|
|
|
SYM_DATA(kexec_va_control_page, .quad 0)
|
|
|
|
|
SYM_DATA(kexec_pa_table_page, .quad 0)
|
|
|
|
|
SYM_DATA(kexec_pa_swap_page, .quad 0)
|
2024-12-05 15:05:15 +00:00
|
|
|
SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
|
2025-03-26 14:16:02 +00:00
|
|
|
SYM_DATA(kexec_debug_8250_mmio32, .quad 0)
|
2025-03-26 14:16:01 +00:00
|
|
|
SYM_DATA(kexec_debug_8250_port, .word 0)
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2025-03-12 14:34:13 +00:00
|
|
|
.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)
|
|
|
|
|
|
2025-03-14 17:27:33 +00:00
|
|
|
.balign 8
|
|
|
|
|
SYM_DATA_START(kexec_debug_idt)
|
|
|
|
|
.skip 0x100, 0x00
|
|
|
|
|
SYM_DATA_END(kexec_debug_idt)
|
|
|
|
|
|
2025-01-09 14:04:17 +00:00
|
|
|
.section .text..relocate_kernel,"ax";
|
2005-06-25 14:58:02 -07:00
|
|
|
.code64
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_START_NOALIGN(relocate_kernel)
|
2023-03-01 07:13:12 -08:00
|
|
|
UNWIND_HINT_END_OF_STACK
|
2022-03-08 16:30:40 +01:00
|
|
|
ANNOTATE_NOENDBR
|
2009-03-10 10:56:57 +08:00
|
|
|
/*
|
|
|
|
|
* %rdi indirection_page
|
2024-12-05 15:05:16 +00:00
|
|
|
* %rsi pa_control_page
|
2006-09-26 10:52:38 +02:00
|
|
|
* %rdx start address
|
2009-03-10 10:57:16 +08:00
|
|
|
* %rcx preserve_context
|
2021-09-08 17:58:36 -05:00
|
|
|
* %r8 host_mem_enc_active
|
2006-09-26 10:52:38 +02:00
|
|
|
*/
|
|
|
|
|
|
2009-03-10 10:57:16 +08:00
|
|
|
/* Save the CPU context, used for jumping back */
|
|
|
|
|
pushq %rbx
|
|
|
|
|
pushq %rbp
|
|
|
|
|
pushq %r12
|
|
|
|
|
pushq %r13
|
|
|
|
|
pushq %r14
|
|
|
|
|
pushq %r15
|
|
|
|
|
pushf
|
|
|
|
|
|
2025-03-26 14:16:03 +00:00
|
|
|
/* Invalidate GDT/IDT, zero out flags */
|
|
|
|
|
pushq $0
|
|
|
|
|
pushq $0
|
|
|
|
|
|
|
|
|
|
lidt (%rsp)
|
|
|
|
|
lgdt (%rsp)
|
|
|
|
|
addq $8, %rsp
|
2005-06-25 14:58:02 -07:00
|
|
|
popfq
|
|
|
|
|
|
2024-12-05 15:05:17 +00:00
|
|
|
/* Switch to the identity mapped page tables */
|
|
|
|
|
movq %cr3, %rax
|
|
|
|
|
movq kexec_pa_table_page(%rip), %r9
|
|
|
|
|
movq %r9, %cr3
|
2017-07-28 11:01:16 -05:00
|
|
|
|
2025-01-09 14:04:13 +00:00
|
|
|
/* Leave CR4 in %r13 to enable the right paging mode later. */
|
|
|
|
|
movq %cr4, %r13
|
2006-09-26 10:52:38 +02:00
|
|
|
|
2025-01-09 14:04:13 +00:00
|
|
|
/* Disable global pages immediately to ensure this mapping is RWX */
|
|
|
|
|
movq %r13, %r12
|
|
|
|
|
andq $~(X86_CR4_PGE), %r12
|
|
|
|
|
movq %r12, %cr4
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2024-12-05 15:05:17 +00:00
|
|
|
/* Save %rsp and CRs. */
|
2025-01-09 14:04:13 +00:00
|
|
|
movq %r13, saved_cr4(%rip)
|
2024-12-05 15:05:17 +00:00
|
|
|
movq %rsp, saved_rsp(%rip)
|
|
|
|
|
movq %rax, saved_cr3(%rip)
|
|
|
|
|
movq %cr0, %rax
|
|
|
|
|
movq %rax, saved_cr0(%rip)
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2024-12-05 15:05:16 +00:00
|
|
|
/* save indirection list for jumping back */
|
2024-12-05 15:05:15 +00:00
|
|
|
movq %rdi, pa_backup_pages_map(%rip)
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2024-12-05 15:05:08 +00:00
|
|
|
/* Save the preserve_context to %r11 as swap_pages clobbers %rcx. */
|
|
|
|
|
movq %rcx, %r11
|
2006-09-26 10:52:38 +02:00
|
|
|
|
|
|
|
|
/* setup a new stack at the end of the physical control page */
|
2024-12-05 15:05:18 +00:00
|
|
|
lea PAGE_SIZE(%rsi), %rsp
|
2006-09-26 10:52:38 +02:00
|
|
|
|
|
|
|
|
/* jump to identity mapped page */
|
2025-01-09 14:04:20 +00:00
|
|
|
0: addq $identity_mapped - 0b, %rsi
|
|
|
|
|
subq $__relocate_kernel_start - 0b, %rsi
|
|
|
|
|
ANNOTATE_RETPOLINE_SAFE
|
|
|
|
|
jmp *%rsi
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_END(relocate_kernel)
|
2006-09-26 10:52:38 +02:00
|
|
|
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
|
2023-03-01 07:13:12 -08:00
|
|
|
UNWIND_HINT_END_OF_STACK
|
2024-12-05 15:05:08 +00:00
|
|
|
/*
|
|
|
|
|
* %rdi indirection page
|
|
|
|
|
* %rdx start address
|
2024-12-05 15:05:18 +00:00
|
|
|
* %r8 host_mem_enc_active
|
|
|
|
|
* %r9 page table page
|
2024-12-05 15:05:08 +00:00
|
|
|
* %r11 preserve_context
|
|
|
|
|
* %r13 original CR4 when relocate_kernel() was invoked
|
|
|
|
|
*/
|
|
|
|
|
|
2006-09-26 10:52:38 +02:00
|
|
|
/* store the start address on the stack */
|
|
|
|
|
pushq %rdx
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2025-03-12 14:34:13 +00:00
|
|
|
/* 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
|
|
|
|
|
|
2025-03-14 17:27:33 +00:00
|
|
|
/* 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
|
|
|
|
|
|
2022-03-08 16:30:36 +01:00
|
|
|
/*
|
|
|
|
|
* Clear X86_CR4_CET (if it was set) such that we can clear CR0_WP
|
|
|
|
|
* below.
|
|
|
|
|
*/
|
|
|
|
|
movq %cr4, %rax
|
|
|
|
|
andq $~(X86_CR4_CET), %rax
|
|
|
|
|
movq %rax, %cr4
|
|
|
|
|
|
2009-03-10 10:56:57 +08:00
|
|
|
/*
|
|
|
|
|
* Set cr0 to a known state:
|
2008-03-23 00:00:08 +03:00
|
|
|
* - Paging enabled
|
|
|
|
|
* - Alignment check disabled
|
|
|
|
|
* - Write protect disabled
|
|
|
|
|
* - No task switch
|
|
|
|
|
* - Don't do FP software emulation.
|
2021-03-21 22:28:53 +01:00
|
|
|
* - Protected mode enabled
|
2005-06-25 14:58:02 -07:00
|
|
|
*/
|
|
|
|
|
movq %cr0, %rax
|
2008-03-23 00:00:08 +03:00
|
|
|
andq $~(X86_CR0_AM | X86_CR0_WP | X86_CR0_TS | X86_CR0_EM), %rax
|
|
|
|
|
orl $(X86_CR0_PG | X86_CR0_PE), %eax
|
2005-06-25 14:58:02 -07:00
|
|
|
movq %rax, %cr0
|
|
|
|
|
|
2009-03-10 10:56:57 +08:00
|
|
|
/*
|
|
|
|
|
* Set cr4 to a known state:
|
2008-03-23 00:00:08 +03:00
|
|
|
* - physical address extension enabled
|
2018-01-29 14:08:45 +03:00
|
|
|
* - 5-level paging, if it was enabled before
|
2024-06-14 12:58:51 +03:00
|
|
|
* - Machine check exception on TDX guest, if it was enabled before.
|
|
|
|
|
* Clearing MCE might not be allowed in TDX guests, depending on setup.
|
|
|
|
|
*
|
|
|
|
|
* Use R13 that contains the original CR4 value, read in relocate_kernel().
|
|
|
|
|
* PAE is always set in the original CR4.
|
2005-06-25 14:58:02 -07:00
|
|
|
*/
|
2024-06-14 12:58:51 +03:00
|
|
|
andl $(X86_CR4_PAE | X86_CR4_LA57), %r13d
|
|
|
|
|
ALTERNATIVE "", __stringify(orl $X86_CR4_MCE, %r13d), X86_FEATURE_TDX_GUEST
|
|
|
|
|
movq %r13, %cr4
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2009-02-03 14:22:48 +08:00
|
|
|
/* Flush the TLB (needed?) */
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %r9, %cr3
|
|
|
|
|
|
2017-07-28 11:01:16 -05:00
|
|
|
/*
|
|
|
|
|
* If SME is active, there could be old encrypted cache line
|
|
|
|
|
* entries that will conflict with the now unencrypted memory
|
|
|
|
|
* used by kexec. Flush the caches before copying the kernel.
|
|
|
|
|
*/
|
2024-12-05 15:05:18 +00:00
|
|
|
testq %r8, %r8
|
2024-06-14 12:58:50 +03:00
|
|
|
jz .Lsme_off
|
2017-07-28 11:01:16 -05:00
|
|
|
wbinvd
|
2024-06-14 12:58:50 +03:00
|
|
|
.Lsme_off:
|
2017-07-28 11:01:16 -05:00
|
|
|
|
2009-03-10 10:57:16 +08:00
|
|
|
call swap_pages
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* To be certain of avoiding problems with self-modifying code
|
|
|
|
|
* I need to execute a serializing instruction here.
|
|
|
|
|
* So I flush the TLB by reloading %cr3 here, it's handy,
|
|
|
|
|
* and not processor dependent.
|
|
|
|
|
*/
|
|
|
|
|
movq %cr3, %rax
|
|
|
|
|
movq %rax, %cr3
|
|
|
|
|
|
2024-12-05 15:05:08 +00:00
|
|
|
testq %r11, %r11 /* preserve_context */
|
|
|
|
|
jnz .Lrelocate
|
|
|
|
|
|
2009-03-10 10:57:16 +08:00
|
|
|
/*
|
|
|
|
|
* set all of the registers to known values
|
|
|
|
|
* leave %rsp alone
|
|
|
|
|
*/
|
|
|
|
|
|
2013-06-20 21:16:00 -07:00
|
|
|
xorl %eax, %eax
|
|
|
|
|
xorl %ebx, %ebx
|
|
|
|
|
xorl %ecx, %ecx
|
|
|
|
|
xorl %edx, %edx
|
|
|
|
|
xorl %esi, %esi
|
|
|
|
|
xorl %edi, %edi
|
|
|
|
|
xorl %ebp, %ebp
|
|
|
|
|
xorl %r8d, %r8d
|
|
|
|
|
xorl %r9d, %r9d
|
|
|
|
|
xorl %r10d, %r10d
|
|
|
|
|
xorl %r11d, %r11d
|
|
|
|
|
xorl %r12d, %r12d
|
|
|
|
|
xorl %r13d, %r13d
|
|
|
|
|
xorl %r14d, %r14d
|
|
|
|
|
xorl %r15d, %r15d
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2022-07-08 19:10:11 +02:00
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
|
|
|
|
int3
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2024-06-14 12:58:50 +03:00
|
|
|
.Lrelocate:
|
2009-03-10 10:57:16 +08:00
|
|
|
popq %rdx
|
x86/kexec: Fix stack and handling of re-entry point for ::preserve_context
A ::preserve_context kimage can be invoked more than once, and the entry point
can be different every time. When the callee returns to the kernel, it leaves
the address of its entry point for next time on the stack.
That being the case, one might reasonably assume that the caller would
allocate space for it on the stack frame before actually performing the 'call'
into the callee.
Apparently not, though. Ever since the kjump code was first added in 2009, it
has set up a *new* stack at the top of the swap_page scratch page, then just
performed the 'call' without allocating any space for the re-entry address to
be returned. It then reads the re-entry point for next time from 0(%rsp) which
is actually the first qword of the page *after* the swap page, which might not
exist at all! And if the callee has written to that, then it will have
corrupted memory it doesn't own.
Correct this by pushing the entry point of the callee onto the stack before
calling it. The callee may then adjust it, or not, as it sees fit, and
subsequent invocations should work correctly either way.
Remove a stray push of zero to the *relocate_kernel* stack, which may have
been intended for this purpose, but which was actually just noise.
Also, loading the stack for the callee relied on the address of the swap page
being in %r10 without ever documenting that fact. Recent code changes made
that no longer true, so load it directly from the local kexec_pa_swap_page
variable instead.
Fixes: b3adabae8a96 ("x86/kexec: Drop page_list argument from relocate_kernel()")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250109140757.2841269-5-dwmw2@infradead.org
2025-01-09 14:04:16 +00:00
|
|
|
|
|
|
|
|
/* Use the swap page for the callee's stack */
|
|
|
|
|
movq kexec_pa_swap_page(%rip), %r10
|
2009-03-10 10:57:16 +08:00
|
|
|
leaq PAGE_SIZE(%r10), %rsp
|
x86/kexec: Fix stack and handling of re-entry point for ::preserve_context
A ::preserve_context kimage can be invoked more than once, and the entry point
can be different every time. When the callee returns to the kernel, it leaves
the address of its entry point for next time on the stack.
That being the case, one might reasonably assume that the caller would
allocate space for it on the stack frame before actually performing the 'call'
into the callee.
Apparently not, though. Ever since the kjump code was first added in 2009, it
has set up a *new* stack at the top of the swap_page scratch page, then just
performed the 'call' without allocating any space for the re-entry address to
be returned. It then reads the re-entry point for next time from 0(%rsp) which
is actually the first qword of the page *after* the swap page, which might not
exist at all! And if the callee has written to that, then it will have
corrupted memory it doesn't own.
Correct this by pushing the entry point of the callee onto the stack before
calling it. The callee may then adjust it, or not, as it sees fit, and
subsequent invocations should work correctly either way.
Remove a stray push of zero to the *relocate_kernel* stack, which may have
been intended for this purpose, but which was actually just noise.
Also, loading the stack for the callee relied on the address of the swap page
being in %r10 without ever documenting that fact. Recent code changes made
that no longer true, so load it directly from the local kexec_pa_swap_page
variable instead.
Fixes: b3adabae8a96 ("x86/kexec: Drop page_list argument from relocate_kernel()")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250109140757.2841269-5-dwmw2@infradead.org
2025-01-09 14:04:16 +00:00
|
|
|
|
|
|
|
|
/* push the existing entry point onto the callee's stack */
|
|
|
|
|
pushq %rdx
|
|
|
|
|
|
2020-03-24 15:35:42 +01:00
|
|
|
ANNOTATE_RETPOLINE_SAFE
|
2009-03-10 10:57:16 +08:00
|
|
|
call *%rdx
|
|
|
|
|
|
|
|
|
|
/* get the re-entry point of the peer system */
|
x86/kexec: Fix stack and handling of re-entry point for ::preserve_context
A ::preserve_context kimage can be invoked more than once, and the entry point
can be different every time. When the callee returns to the kernel, it leaves
the address of its entry point for next time on the stack.
That being the case, one might reasonably assume that the caller would
allocate space for it on the stack frame before actually performing the 'call'
into the callee.
Apparently not, though. Ever since the kjump code was first added in 2009, it
has set up a *new* stack at the top of the swap_page scratch page, then just
performed the 'call' without allocating any space for the re-entry address to
be returned. It then reads the re-entry point for next time from 0(%rsp) which
is actually the first qword of the page *after* the swap page, which might not
exist at all! And if the callee has written to that, then it will have
corrupted memory it doesn't own.
Correct this by pushing the entry point of the callee onto the stack before
calling it. The callee may then adjust it, or not, as it sees fit, and
subsequent invocations should work correctly either way.
Remove a stray push of zero to the *relocate_kernel* stack, which may have
been intended for this purpose, but which was actually just noise.
Also, loading the stack for the callee relied on the address of the swap page
being in %r10 without ever documenting that fact. Recent code changes made
that no longer true, so load it directly from the local kexec_pa_swap_page
variable instead.
Fixes: b3adabae8a96 ("x86/kexec: Drop page_list argument from relocate_kernel()")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250109140757.2841269-5-dwmw2@infradead.org
2025-01-09 14:04:16 +00:00
|
|
|
popq %rbp
|
2024-12-05 15:05:16 +00:00
|
|
|
movq kexec_pa_swap_page(%rip), %r10
|
2024-12-05 15:05:15 +00:00
|
|
|
movq pa_backup_pages_map(%rip), %rdi
|
2024-12-05 15:05:16 +00:00
|
|
|
movq kexec_pa_table_page(%rip), %rax
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rax, %cr3
|
2025-01-09 14:04:20 +00:00
|
|
|
|
|
|
|
|
/* Find start (and end) of this physical mapping of control page */
|
|
|
|
|
leaq (%rip), %r8
|
|
|
|
|
ANNOTATE_NOENDBR
|
|
|
|
|
andq $PAGE_MASK, %r8
|
2009-03-10 10:57:16 +08:00
|
|
|
lea PAGE_SIZE(%r8), %rsp
|
2025-01-09 14:04:14 +00:00
|
|
|
movl $1, %r11d /* Ensure preserve_context flag is set */
|
2009-03-10 10:57:16 +08:00
|
|
|
call swap_pages
|
2024-12-05 15:05:16 +00:00
|
|
|
movq kexec_va_control_page(%rip), %rax
|
2025-01-09 14:04:20 +00:00
|
|
|
0: addq $virtual_mapped - 0b, %rax
|
|
|
|
|
subq $__relocate_kernel_start - 0b, %rax
|
2009-03-10 10:57:16 +08:00
|
|
|
pushq %rax
|
2022-07-08 19:10:11 +02:00
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
|
|
|
|
int3
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_END(identity_mapped)
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_START_LOCAL_NOALIGN(virtual_mapped)
|
2023-03-01 07:13:12 -08:00
|
|
|
UNWIND_HINT_END_OF_STACK
|
2022-03-08 16:30:40 +01:00
|
|
|
ANNOTATE_NOENDBR // RET target, above
|
2024-12-05 15:05:15 +00:00
|
|
|
movq saved_rsp(%rip), %rsp
|
|
|
|
|
movq saved_cr4(%rip), %rax
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rax, %cr4
|
2024-12-05 15:05:15 +00:00
|
|
|
movq saved_cr3(%rip), %rax
|
|
|
|
|
movq saved_cr0(%rip), %r8
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rax, %cr3
|
|
|
|
|
movq %r8, %cr0
|
x86/kexec: Restore GDT on return from ::preserve_context kexec
The restore_processor_state() function explicitly states that "the asm code
that gets us here will have restored a usable GDT". That wasn't true in the
case of returning from a ::preserve_context kexec. Make it so.
Without this, the kernel was depending on the called function to reload a
GDT which is appropriate for the kernel before returning.
Test program:
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/kexec.h>
#include <linux/reboot.h>
#include <sys/reboot.h>
#include <sys/syscall.h>
int main (void)
{
struct kexec_segment segment = {};
unsigned char purgatory[] = {
0x66, 0xba, 0xf8, 0x03, // mov $0x3f8, %dx
0xb0, 0x42, // mov $0x42, %al
0xee, // outb %al, (%dx)
0xc3, // ret
};
int ret;
segment.buf = &purgatory;
segment.bufsz = sizeof(purgatory);
segment.mem = (void *)0x400000;
segment.memsz = 0x1000;
ret = syscall(__NR_kexec_load, 0x400000, 1, &segment, KEXEC_PRESERVE_CONTEXT);
if (ret) {
perror("kexec_load");
exit(1);
}
ret = syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC);
if (ret) {
perror("kexec reboot");
exit(1);
}
printf("Success\n");
return 0;
}
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20241205153343.3275139-2-dwmw2@infradead.org
2024-12-05 15:05:07 +00:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_KEXEC_JUMP
|
|
|
|
|
/* Saved in save_processor_state. */
|
|
|
|
|
movq $saved_context, %rax
|
|
|
|
|
lgdt saved_context_gdt_desc(%rax)
|
|
|
|
|
#endif
|
|
|
|
|
|
x86/kexec: Fix stack and handling of re-entry point for ::preserve_context
A ::preserve_context kimage can be invoked more than once, and the entry point
can be different every time. When the callee returns to the kernel, it leaves
the address of its entry point for next time on the stack.
That being the case, one might reasonably assume that the caller would
allocate space for it on the stack frame before actually performing the 'call'
into the callee.
Apparently not, though. Ever since the kjump code was first added in 2009, it
has set up a *new* stack at the top of the swap_page scratch page, then just
performed the 'call' without allocating any space for the re-entry address to
be returned. It then reads the re-entry point for next time from 0(%rsp) which
is actually the first qword of the page *after* the swap page, which might not
exist at all! And if the callee has written to that, then it will have
corrupted memory it doesn't own.
Correct this by pushing the entry point of the callee onto the stack before
calling it. The callee may then adjust it, or not, as it sees fit, and
subsequent invocations should work correctly either way.
Remove a stray push of zero to the *relocate_kernel* stack, which may have
been intended for this purpose, but which was actually just noise.
Also, loading the stack for the callee relied on the address of the swap page
being in %r10 without ever documenting that fact. Recent code changes made
that no longer true, so load it directly from the local kexec_pa_swap_page
variable instead.
Fixes: b3adabae8a96 ("x86/kexec: Drop page_list argument from relocate_kernel()")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250109140757.2841269-5-dwmw2@infradead.org
2025-01-09 14:04:16 +00:00
|
|
|
/* relocate_kernel() returns the re-entry point for next time */
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rbp, %rax
|
|
|
|
|
|
|
|
|
|
popf
|
|
|
|
|
popq %r15
|
|
|
|
|
popq %r14
|
|
|
|
|
popq %r13
|
|
|
|
|
popq %r12
|
|
|
|
|
popq %rbp
|
|
|
|
|
popq %rbx
|
2022-07-08 19:10:11 +02:00
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
|
|
|
|
int3
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_END(virtual_mapped)
|
2005-06-25 14:58:02 -07:00
|
|
|
|
|
|
|
|
/* Do the copies */
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
|
2023-03-01 07:13:12 -08:00
|
|
|
UNWIND_HINT_END_OF_STACK
|
2025-01-09 14:04:15 +00:00
|
|
|
/*
|
|
|
|
|
* %rdi indirection page
|
|
|
|
|
* %r11 preserve_context
|
|
|
|
|
*/
|
2024-08-25 20:18:05 +12:00
|
|
|
movq %rdi, %rcx /* Put the indirection_page in %rcx */
|
2013-06-20 21:16:00 -07:00
|
|
|
xorl %edi, %edi
|
|
|
|
|
xorl %esi, %esi
|
2024-12-05 15:05:09 +00:00
|
|
|
jmp .Lstart /* Should start with an indirection record */
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2024-12-05 15:05:09 +00:00
|
|
|
.Lloop: /* top, read another word for the indirection page */
|
2005-06-25 14:58:02 -07:00
|
|
|
|
|
|
|
|
movq (%rbx), %rcx
|
|
|
|
|
addq $8, %rbx
|
2024-12-05 15:05:09 +00:00
|
|
|
.Lstart:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 21:55:32 +01:00
|
|
|
testb $0x1, %cl /* is it a destination page? */
|
2024-12-05 15:05:09 +00:00
|
|
|
jz .Lnotdest
|
2005-06-25 14:58:02 -07:00
|
|
|
movq %rcx, %rdi
|
|
|
|
|
andq $0xfffffffffffff000, %rdi
|
2024-12-05 15:05:09 +00:00
|
|
|
jmp .Lloop
|
|
|
|
|
.Lnotdest:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 21:55:32 +01:00
|
|
|
testb $0x2, %cl /* is it an indirection page? */
|
2024-12-05 15:05:09 +00:00
|
|
|
jz .Lnotind
|
2005-06-25 14:58:02 -07:00
|
|
|
movq %rcx, %rbx
|
|
|
|
|
andq $0xfffffffffffff000, %rbx
|
2024-12-05 15:05:09 +00:00
|
|
|
jmp .Lloop
|
|
|
|
|
.Lnotind:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 21:55:32 +01:00
|
|
|
testb $0x4, %cl /* is it the done indicator? */
|
2024-12-05 15:05:09 +00:00
|
|
|
jz .Lnotdone
|
|
|
|
|
jmp .Ldone
|
|
|
|
|
.Lnotdone:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 21:55:32 +01:00
|
|
|
testb $0x8, %cl /* is it the source indicator? */
|
2024-12-05 15:05:09 +00:00
|
|
|
jz .Lloop /* Ignore it otherwise */
|
2005-06-25 14:58:02 -07:00
|
|
|
movq %rcx, %rsi /* For ever source page do a copy */
|
|
|
|
|
andq $0xfffffffffffff000, %rsi
|
|
|
|
|
|
2024-08-25 20:18:06 +12:00
|
|
|
movq %rdi, %rdx /* Save destination page to %rdx */
|
|
|
|
|
movq %rsi, %rax /* Save source page to %rax */
|
2009-03-10 10:57:16 +08:00
|
|
|
|
2024-12-05 15:05:10 +00:00
|
|
|
testq %r11, %r11 /* Only actually swap for ::preserve_context */
|
|
|
|
|
jz .Lnoswap
|
|
|
|
|
|
2024-08-25 20:18:06 +12:00
|
|
|
/* copy source page to swap page */
|
2025-01-09 14:04:15 +00:00
|
|
|
movq kexec_pa_swap_page(%rip), %rdi
|
2015-03-31 19:00:10 +02:00
|
|
|
movl $512, %ecx
|
2025-04-18 09:13:51 +02:00
|
|
|
rep movsq
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2024-08-25 20:18:06 +12:00
|
|
|
/* copy destination page to source page */
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rax, %rdi
|
|
|
|
|
movq %rdx, %rsi
|
2015-03-31 19:00:10 +02:00
|
|
|
movl $512, %ecx
|
2025-04-18 09:13:51 +02:00
|
|
|
rep movsq
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2024-08-25 20:18:06 +12:00
|
|
|
/* copy swap page to destination page */
|
2009-03-10 10:57:16 +08:00
|
|
|
movq %rdx, %rdi
|
2025-01-09 14:04:15 +00:00
|
|
|
movq kexec_pa_swap_page(%rip), %rsi
|
2024-12-05 15:05:10 +00:00
|
|
|
.Lnoswap:
|
2015-03-31 19:00:10 +02:00
|
|
|
movl $512, %ecx
|
2025-04-18 09:13:51 +02:00
|
|
|
rep movsq
|
2005-06-25 14:58:02 -07:00
|
|
|
|
2009-03-10 10:57:16 +08:00
|
|
|
lea PAGE_SIZE(%rax), %rsi
|
2024-12-05 15:05:09 +00:00
|
|
|
jmp .Lloop
|
|
|
|
|
.Ldone:
|
2022-07-08 19:10:11 +02:00
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
|
|
|
|
int3
|
2019-10-11 13:50:43 +02:00
|
|
|
SYM_CODE_END(swap_pages)
|
2025-03-14 17:27:33 +00:00
|
|
|
|
2025-03-14 17:27:34 +00:00
|
|
|
/*
|
2025-03-26 14:16:01 +00:00
|
|
|
* Generic 'print character' routine
|
2025-03-14 17:27:34 +00:00
|
|
|
* - %al: Character to be printed (may clobber %rax)
|
|
|
|
|
* - %rdx: MMIO address or port.
|
|
|
|
|
*/
|
2025-03-26 14:16:01 +00:00
|
|
|
#define XMTRDY 0x20
|
|
|
|
|
|
|
|
|
|
#define TXR 0 /* Transmit register (WRITE) */
|
|
|
|
|
#define LSR 5 /* Line Status */
|
|
|
|
|
|
|
|
|
|
SYM_CODE_START_LOCAL_NOALIGN(pr_char_8250)
|
2025-03-14 17:27:34 +00:00
|
|
|
UNWIND_HINT_FUNC
|
|
|
|
|
ANNOTATE_NOENDBR
|
2025-03-26 14:16:01 +00:00
|
|
|
addw $LSR, %dx
|
|
|
|
|
xchg %al, %ah
|
|
|
|
|
.Lxmtrdy_loop:
|
|
|
|
|
inb %dx, %al
|
|
|
|
|
testb $XMTRDY, %al
|
|
|
|
|
jnz .Lready
|
2025-04-18 10:07:44 +02:00
|
|
|
pause
|
2025-03-26 14:16:01 +00:00
|
|
|
jmp .Lxmtrdy_loop
|
|
|
|
|
|
|
|
|
|
.Lready:
|
|
|
|
|
subw $LSR, %dx
|
|
|
|
|
xchg %al, %ah
|
|
|
|
|
outb %al, %dx
|
|
|
|
|
pr_char_null:
|
|
|
|
|
ANNOTATE_NOENDBR
|
|
|
|
|
|
2025-03-14 17:27:34 +00:00
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
2025-03-26 14:16:01 +00:00
|
|
|
SYM_CODE_END(pr_char_8250)
|
2025-03-14 17:27:34 +00:00
|
|
|
|
2025-03-26 14:16:02 +00:00
|
|
|
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
|
2025-04-18 10:07:44 +02:00
|
|
|
pause
|
2025-03-26 14:16:02 +00:00
|
|
|
jmp .Lxmtrdy_loop_mmio
|
|
|
|
|
|
|
|
|
|
.Lready_mmio:
|
|
|
|
|
movb %al, (%rdx)
|
|
|
|
|
ANNOTATE_UNRET_SAFE
|
|
|
|
|
ret
|
|
|
|
|
SYM_CODE_END(pr_char_8250_mmio32)
|
|
|
|
|
|
2025-03-14 17:27:34 +00:00
|
|
|
/*
|
|
|
|
|
* Load pr_char function pointer into %rsi and load %rdx with whatever
|
|
|
|
|
* that function wants to see there (typically port/MMIO address).
|
|
|
|
|
*/
|
2025-03-26 14:16:01 +00:00
|
|
|
.macro pr_setup
|
|
|
|
|
leaq pr_char_8250(%rip), %rsi
|
|
|
|
|
movw kexec_debug_8250_port(%rip), %dx
|
|
|
|
|
testw %dx, %dx
|
|
|
|
|
jnz 1f
|
|
|
|
|
|
2025-03-26 14:16:02 +00:00
|
|
|
leaq pr_char_8250_mmio32(%rip), %rsi
|
|
|
|
|
movq kexec_debug_8250_mmio32(%rip), %rdx
|
|
|
|
|
testq %rdx, %rdx
|
|
|
|
|
jnz 1f
|
|
|
|
|
|
2025-03-26 14:16:01 +00:00
|
|
|
leaq pr_char_null(%rip), %rsi
|
|
|
|
|
1:
|
2025-03-14 17:27:34 +00:00
|
|
|
.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
|
|
|
|
|
|
2025-03-14 17:27:33 +00:00
|
|
|
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)
|
|
|
|
|
/* No need for RET mitigations during kexec */
|
|
|
|
|
VALIDATE_UNRET_END
|
|
|
|
|
|
|
|
|
|
pushq %rax
|
2025-03-14 17:27:34 +00:00
|
|
|
pushq %rbx
|
|
|
|
|
pushq %rcx
|
2025-03-14 17:27:33 +00:00
|
|
|
pushq %rdx
|
2025-03-14 17:27:34 +00:00
|
|
|
pushq %rsi
|
|
|
|
|
|
|
|
|
|
/* Stack frame */
|
|
|
|
|
#define EXC_SS 0x58 /* Architectural... */
|
|
|
|
|
#define EXC_RSP 0x50
|
|
|
|
|
#define EXC_EFLAGS 0x48
|
|
|
|
|
#define EXC_CS 0x40
|
|
|
|
|
#define EXC_RIP 0x38
|
|
|
|
|
#define EXC_ERRORCODE 0x30 /* Either architectural or zero pushed by handler */
|
|
|
|
|
#define EXC_EXCEPTION 0x28 /* Pushed by handler entry point */
|
|
|
|
|
#define EXC_RAX 0x20 /* Pushed just above in exc_handler */
|
|
|
|
|
#define EXC_RBX 0x18
|
|
|
|
|
#define EXC_RCX 0x10
|
|
|
|
|
#define EXC_RDX 0x08
|
|
|
|
|
#define EXC_RSI 0x00
|
|
|
|
|
|
|
|
|
|
/* Set up %rdx/%rsi for debug output */
|
|
|
|
|
pr_setup
|
|
|
|
|
|
|
|
|
|
/* rip and exception info */
|
|
|
|
|
print_reg 'E', 'x', 'c', ':', EXC_EXCEPTION(%rsp)
|
|
|
|
|
print_reg 'E', 'r', 'r', ':', EXC_ERRORCODE(%rsp)
|
|
|
|
|
print_reg 'r', 'i', 'p', ':', EXC_RIP(%rsp)
|
|
|
|
|
print_reg 'r', 's', 'p', ':', EXC_RSP(%rsp)
|
|
|
|
|
|
|
|
|
|
/* We spilled these to the stack */
|
|
|
|
|
print_reg 'r', 'a', 'x', ':', EXC_RAX(%rsp)
|
|
|
|
|
print_reg 'r', 'b', 'x', ':', EXC_RBX(%rsp)
|
|
|
|
|
print_reg 'r', 'c', 'x', ':', EXC_RCX(%rsp)
|
|
|
|
|
print_reg 'r', 'd', 'x', ':', EXC_RDX(%rsp)
|
|
|
|
|
print_reg 'r', 's', 'i', ':', EXC_RSI(%rsp)
|
|
|
|
|
|
|
|
|
|
/* Other registers untouched */
|
|
|
|
|
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
|
2025-03-14 17:27:33 +00:00
|
|
|
|
|
|
|
|
/* Only return from INT3 */
|
2025-03-14 17:27:34 +00:00
|
|
|
cmpq $3, EXC_EXCEPTION(%rsp)
|
2025-03-14 17:27:33 +00:00
|
|
|
jne .Ldie
|
|
|
|
|
|
2025-03-14 17:27:34 +00:00
|
|
|
popq %rsi
|
|
|
|
|
popq %rdx
|
|
|
|
|
popq %rcx
|
|
|
|
|
popq %rbx
|
|
|
|
|
popq %rax
|
|
|
|
|
|
2025-03-14 17:27:33 +00:00
|
|
|
addq $16, %rsp
|
|
|
|
|
iretq
|
|
|
|
|
|
|
|
|
|
.Ldie:
|
|
|
|
|
hlt
|
|
|
|
|
jmp .Ldie
|
|
|
|
|
|
|
|
|
|
SYM_CODE_END(exc_handler)
|