Messages in this thread | | | Date | Tue, 31 Jan 2023 18:25:04 -0800 | Subject | Re: [PATCH 3/7] x86/cpu: Disable kernel LASS when patching kernel alternatives | From | Sohil Mehta <> |
| |
On 1/12/2023 10:48 AM, Dave Hansen wrote: > Also, Andy Cooper made a very good point: when the kernel enables > paging, it's running with a low address so that the instruction pointer > stays valid as paging becomes enabled. > > But, if LASS were enabled and enforced at that point, you'd get a LASS > fault and go kablooey. Can you see what simics does in that case, and > also make sure we're clearing CR4.LASS when enabling paging? That would > obviate the need to do it later in C code too.
CR4 and CR0 are always restored to a known state during kexec. So, running with LASS enabled should not happen during early boot.
machine_kexec() -> relocate_kernel() -> identity_mapped()
> /* > * Set cr0 to a known state: > * - Paging enabled > * - Alignment check disabled > * - Write protect disabled > * - No task switch > * - Don't do FP software emulation. > * - Protected mode enabled > */ > movq %cr0, %rax > andq $~(X86_CR0_AM | X86_CR0_WP | X86_CR0_TS | X86_CR0_EM), %rax > orl $(X86_CR0_PG | X86_CR0_PE), %eax > movq %rax, %cr0 > > /* > * Set cr4 to a known state: > * - physical address extension enabled > * - 5-level paging, if it was enabled before > */ > movl $X86_CR4_PAE, %eax > testq $X86_CR4_LA57, %r13 > jz 1f > orl $X86_CR4_LA57, %eax > 1: > movq %rax, %cr4 > > jmp 1f > 1:
Dave, does this address your concern or were you looking for something else? Is there some path other than kexec that should also be audited for this scenario?
| |