Re: [PATCHv6 05/16] x86/cpu: Defer CR pinning setup until after EFI initialization

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

 



On 6/20/25 06:53, Kirill A. Shutemov wrote:
>  	/*
>  	 * This needs to follow the FPU initializtion, since EFI depends on it.
> +	 *
> +	 * It also needs to precede the CR pinning setup, because the CR4.LASS
> +	 * bit has to be cleared temporarily in order to execute the
> +	 * set_virtual_address_map() EFI call, which resides in lower addresses
> +	 * and would trip LASS if enabled.
> +	 *
> +	 * Wrapping efi_enter_virtual_mode() into lass_stac()/clac() is not
> +	 * enough because AC flag gates data accesses, but not instruction
> +	 * fetch. Clearing the CR4 bit is required.
>  	 */
>  	if (efi_enabled(EFI_RUNTIME_SERVICES))
>  		efi_enter_virtual_mode();
>  
> +	setup_cr_pinning();

This is a _bit_ too much of a comment for me in this context. This would
be enough:

	/* EFI twiddles CR4.LASS. Do it before CR pinning: */
  	if (efi_enabled(EFI_RUNTIME_SERVICES))
  		efi_enter_virtual_mode();

	setup_cr_pinning();

I also dislike comments where code will do. Could
efi_enter_virtual_mode() actually check for CR4.LASS? Or check
cr4_pinned_bits() or 'cr_pinning.key'?

Also, the "lass_stac()/clac() is not enough" comment seems more like
changelog material to me than something for a comment.




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux