From: Ard Biesheuvel <ardb@xxxxxxxxxx> The code that executes from the early 1:1 mapping of the kernel should set up the kernel page tables and nothing else. C code that is linked into this code path is severely restricted in what it can do, and is therefore required to remain uninstrumented. It also built with -fPIC and without stack protector support. This makes it unnecessary to enable per-CPU variable access this early, and for the boot CPU, the initialization that occurs in the common CPU startup path is sufficient. Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> --- arch/x86/kernel/head_64.S | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 5defefcc7f50..2cce53b2cd70 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -76,13 +76,6 @@ SYM_CODE_START_LOCAL(primary_startup_64) /* Set up the stack for verify_cpu() */ leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp - /* Setup GSBASE to allow stack canary access for C code */ - movl $MSR_GS_BASE, %ecx - leaq INIT_PER_CPU_VAR(fixed_percpu_data)(%rip), %rdx - movl %edx, %eax - shrq $32, %rdx - wrmsr - call startup_64_setup_env /* Now switch to __KERNEL_CS so IRET works reliably */ -- 2.43.0.429.g432eaa2c6b-goog
