Patch "x86/head/64: Switch to KERNEL_CS as soon as new GDT is installed" has been added to the 6.1-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    x86/head/64: Switch to KERNEL_CS as soon as new GDT is installed

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-head-64-switch-to-kernel_cs-as-soon-as-new-gdt-i.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 2b4677a9a690bd26a16213f10725d1fa1f099e8d
Author: Tom Lendacky <thomas.lendacky@xxxxxxx>
Date:   Wed May 17 11:26:41 2023 -0500

    x86/head/64: Switch to KERNEL_CS as soon as new GDT is installed
    
    [ Upstream commit a37f2699c36a7f6606ba3300f243227856c5ad6b ]
    
    The call to startup_64_setup_env() will install a new GDT but does not
    actually switch to using the KERNEL_CS entry until returning from the
    function call.
    
    Commit bcce82908333 ("x86/sev: Detect/setup SEV/SME features earlier in
    boot") moved the call to sme_enable() earlier in the boot process and in
    between the call to startup_64_setup_env() and the switch to KERNEL_CS.
    An SEV-ES or an SEV-SNP guest will trigger #VC exceptions during the call
    to sme_enable() and if the CS pushed on the stack as part of the exception
    and used by IRETQ is not mapped by the new GDT, then problems occur.
    Today, the current CS when entering startup_64 is the kernel CS value
    because it was set up by the decompressor code, so no issue is seen.
    
    However, a recent patchset that looked to avoid using the legacy
    decompressor during an EFI boot exposed this bug. At entry to startup_64,
    the CS value is that of EFI and is not mapped in the new kernel GDT. So
    when a #VC exception occurs, the CS value used by IRETQ is not valid and
    the guest boot crashes.
    
    Fix this issue by moving the block that switches to the KERNEL_CS value to
    be done immediately after returning from startup_64_setup_env().
    
    Fixes: bcce82908333 ("x86/sev: Detect/setup SEV/SME features earlier in boot")
    Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
    Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
    Reviewed-by: Joerg Roedel <jroedel@xxxxxxx>
    Link: https://lore.kernel.org/all/6ff1f28af2829cc9aea357ebee285825f90a431f.1684340801.git.thomas.lendacky%40amd.com
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index d860d437631b6..998cdb112b725 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -85,6 +85,15 @@ SYM_CODE_START_NOALIGN(startup_64)
 	call	startup_64_setup_env
 	popq	%rsi
 
+	/* Now switch to __KERNEL_CS so IRET works reliably */
+	pushq	$__KERNEL_CS
+	leaq	.Lon_kernel_cs(%rip), %rax
+	pushq	%rax
+	lretq
+
+.Lon_kernel_cs:
+	UNWIND_HINT_EMPTY
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 	/*
 	 * Activate SEV/SME memory encryption if supported/enabled. This needs to
@@ -98,15 +107,6 @@ SYM_CODE_START_NOALIGN(startup_64)
 	popq	%rsi
 #endif
 
-	/* Now switch to __KERNEL_CS so IRET works reliably */
-	pushq	$__KERNEL_CS
-	leaq	.Lon_kernel_cs(%rip), %rax
-	pushq	%rax
-	lretq
-
-.Lon_kernel_cs:
-	UNWIND_HINT_EMPTY
-
 	/* Sanitize CPU configuration */
 	call verify_cpu
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux