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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <52e152b9-c840-4480-9337-0f0aca327543@intel.com>
Date: Mon, 9 Feb 2026 16:18:32 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Xin Li <xin@...or.com>, Dave Hansen <dave.hansen@...el.com>
CC: <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()

On 2/8/2026 11:28 PM, Sohil Mehta wrote:
> 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 verified that the above patch works as expected. I added a debug print
in cpu_init_fred_exceptions() to test FRED behavior.

	if (cr4_read_shadow() & X86_CR4_FRED)
		pr_warn("FRED is already enabled on CPU%d\n",
			smp_processor_id());


With Dave's patch, the warning no longer shows up on APs.

However, I found another location where we enable FRED in CR4 before
enabling the MSRs.

__restore_processor_state():

...

  __write_cr4(ctxt->cr4);

...

  if (ctxt->cr4 & X86_CR4_FRED) {
    cpu_init_fred_exceptions();
    cpu_init_fred_rsps();
  }

Due to limitations of my test platform, I couldn't verify the FRED print
in __restore_processor_state()'s path. But, could "restore" run into a
similar issue in the future?