linux-kernel - Re: [PATCH] x86/fred: Fix early boot failures on SEV-ES/SNP guests

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: <02df7890-83c2-4047-8c88-46fbc6e0a892@intel.com>
Date: Thu, 5 Feb 2026 09:20:20 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Nikunj A Dadhania <nikunj@....com>, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, bp@...en8.de, thomas.lendacky@....com
Cc: tglx@...nel.org, mingo@...hat.com, dave.hansen@...ux.intel.com,
 hpa@...or.com, xin@...or.com, seanjc@...gle.com, pbonzini@...hat.com,
 x86@...nel.org, jon.grimm@....com, stable@...r.kernel.org
Subject: Re: [PATCH] x86/fred: Fix early boot failures on SEV-ES/SNP guests

On 2/5/26 08:10, Dave Hansen wrote:
> Shouldn't we flip the FRED CR4 bit _last_, once all the MSRs are set up?
> Why is it backwards in the first place? Why can't it be fixed?

Ahhh, it was done by CR4 pinning. It's the first thing in C code for
booting secondaries:

static void notrace __noendbr start_secondary(void *unused)
{
        cr4_init();

Since FRED is set in 'cr4_pinned_mask', cr4_init() sets the FRED bit far
before the FRED MSRs are ready. Anyone else doing native_write_cr4()
will do the same thing. That's obviously not what was intended from the
pinning code or the FRED init code.

Shouldn't we fix this properly rather than moving printk()'s around?

One idea is just to turn off all the CR-pinning logic while bringing
CPUs up. That way, nothing before:

	set_cpu_online(smp_processor_id(), true);

can get tripped up by CR pinning. I've attached a completely untested
patch to do that.

The other thing would be to make pinning actually per-cpu:
'cr4_pinned_bits' could be per-cpu and we'd just keep it empty until the
CPU is actually booted and everything is fully set up.

Either way, this is looking like it'll be a bit more than one patch to
do properly.
View attachment "no-cr4-pinning-for-offline-cpus.patch" of type "text/x-patch" (1904 bytes)