linux-kernel - Re: [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal in relocate

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: <0c95413047ec3e394d21bc56027bde74f817b423.camel@intel.com>
Date: Wed, 19 Mar 2025 16:20:56 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "tglx@...utronix.de" <tglx@...utronix.de>, "peterz@...radead.org"
	<peterz@...radead.org>, "mingo@...hat.com" <mingo@...hat.com>, "Hansen, Dave"
	<dave.hansen@...el.com>, "Huang, Kai" <kai.huang@...el.com>, "bp@...en8.de"
	<bp@...en8.de>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>
CC: "ashish.kalra@....com" <ashish.kalra@....com>, "dyoung@...hat.com"
	<dyoung@...hat.com>, "thomas.lendacky@....com" <thomas.lendacky@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "dwmw@...zon.co.uk"
	<dwmw@...zon.co.uk>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"bhe@...hat.com" <bhe@...hat.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "nik.borisov@...e.com" <nik.borisov@...e.com>,
	"Chatre, Reinette" <reinette.chatre@...el.com>, "hpa@...or.com"
	<hpa@...or.com>, "sagis@...gle.com" <sagis@...gle.com>,
	"david.kaplan@....com" <david.kaplan@....com>, "x86@...nel.org"
	<x86@...nel.org>, "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal
 in relocate_kernel()

On Wed, 2025-03-19 at 09:57 +0000, Huang, Kai wrote:
> Nevertheless, are you looking for something like below in the changelog?
> 
>   With the 'host_mem_enc_active' and the comment around it removed,
>   the information about depth tracking no longer exists.  Expand the 
>   comment around load_segments() to mention that due to depth tracking
>   no function call can be made after load_segments().

Looks good to me.