linux-kernel - Re: [PATCH v1] x86/smp: Set up exception handling before cr4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5E3DA211-BD18-459F-ADDE-63E24E8C8BEA@zytor.com>
Date: Mon, 9 Feb 2026 00:16:20 -0800
From: Xin Li <xin@...or.com>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        peterz@...radead.org, andrew.cooper3@...rix.com, nikunj@....com,
        thomas.lendacky@....com, seanjc@...gle.com, stable@...r.kernel.org
Subject: Re: [PATCH v1] x86/smp: Set up exception handling before cr4_init()


>> 
>> I’m curious why cr4_init() is not part of the following cpu_init()? IOW,
>> why does it need to be called so early in the existing code?
>> 
> 
> The name cpu_init() is misleading. Most of the pinned features don't get
> initialized in cpu_init(). They are set up slightly later:
> 
> start_secondary()
>  ap_starting()
>    identify_secondary_cpu()
>      identify_cpu()
> 
> The original reason for writing CR4 early on APs probably originates in
> commit c7ad5ad297e6 ("x86/mm/64: Initialize CR4.PCIDE early"). Then,
> when CR pinning was introduced, it was a global system-wide concept. So,
> the pinned bits had to be programmed when the first write to CR4 happened.


Thanks for digging into it and explain it.


> 
>> 
>>> 
>>> I _really_ think we need a defined per-cpu point where pinning comes
>>> into effect. Marking the CPU online is one idea.
>>> 
>>> Thoughts?
>> 
> 
> I think this approach could work. It should cover APs as well as hotplug
> CPUs that come online later.
> 
>> It seems a good fit.  Just that {on,off}line() are not called on BSP (not
>> a real problem).
>> 
> 
> The BSP is marked online in boot_cpu_init()->set_cpu_online(). So, it
> should be covered as well.
> 
>> Question is that who would work on it ;) ?
> 
> I think Dave already posted the patch for it here.
> https://lore.kernel.org/lkml/02df7890-83c2-4047-8c88-46fbc6e0a892@intel.com/
> 
> I will test that out to confirm that it doesn't mess up some implicit
> behavior.
> 

I’m not sure if Dave also wants to make BSP/AP boot code symmetric at the same time ;)