linux-kernel - Re: [PATCH v1 1/1] x86/fred: Fix the FRED RSP0 MSR out of sync with its per CPU cache

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: <a7bc02bd-035b-4930-a569-3438b47ade19@intel.com>
Date: Wed, 8 Jan 2025 12:14:18 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 andrew.cooper3@...rix.com
Subject: Re: [PATCH v1 1/1] x86/fred: Fix the FRED RSP0 MSR out of sync with
 its per CPU cache

On 1/7/25 18:36, Xin Li (Intel) wrote:
> +	 * Another option is to leave the FRED RSP0 MSR as-is, because the RESET
> +	 * state of FRED MSRs is zero and INIT does not change the value of the
> +	 * FRED MSRs in a CPU offline/online cycle.  But it doesn't seem safe to
> +	 * depend on the properties of INIT as that's way too many things that
> +	 * could cause bugs.

Wouldn't that also open us up to kexec problems? If the last kernel
(maybe not even Linux) left RSP0 set, then the current kernel might
eventually try to run userspace with the old kernel's RSP0 value.