linux-kernel - Re: [PATCH v1 1/1] x86/fred: Fix system hang during S4 resume with FRED enabled

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] [day] [month] [year] [list]

Message-ID: <Z-uiXfz1nOP7jGQv@gmail.com>
Date: Tue, 1 Apr 2025 10:22:53 +0200
From: Ingo Molnar <mingo@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	"Xin Li (Intel)" <xin@...or.com>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	pavel@...nel.org, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
	xi.pardee@...el.com, todd.e.brandt@...el.com
Subject: Re: [PATCH v1 1/1] x86/fred: Fix system hang during S4 resume with
 FRED enabled

* H. Peter Anvin <hpa@...or.com> wrote:

> Just to make it clear: the patch is correct, the shortcoming is in 
> the description.
> 
> I would say that Xin's description, although perhaps excessively 
> brief, is correct from the *hardware* point of view, whereas Rafael 
> adds the much needed *software* perspective.

This part of the -v1 patch was a bit misleading to me:

>> Due to changes in the kernel text and data mappings, the FRED MSRs 
>> must be reinitialized.

... as it suggests that the FRED MSRs will change from before the 
suspend - while they don't.

What this sentence meant is that FRED MSRs set up by the intermediate 
*kexec kernel* are incorrect and must be reinitialized again to 
reconstruct the pre-hibernation state. Ie. there's 3 FRED setup states: 
pre-S4, kexec and post-S4, where pre-S4 == post-S4. Right?

I think the description and comments in the -v2 patch are better in 
this regard.

Thanks,

	Ingo