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: <e7d539757247e603e0e5511d1e26bfcd58d308d1.camel@intel.com>
Date: Mon, 30 Jun 2025 11:34:34 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "bp@...en8.de" <bp@...en8.de>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "ashish.kalra@....com"
	<ashish.kalra@....com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, "Chatre,
 Reinette" <reinette.chatre@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"nik.borisov@...e.com" <nik.borisov@...e.com>, "hpa@...or.com"
	<hpa@...or.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"sagis@...gle.com" <sagis@...gle.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "x86@...nel.org" <x86@...nel.org>, "Williams,
 Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v3 1/6] x86/sme: Use percpu boolean to control wbinvd
 during kexec

On Sat, 2025-06-28 at 14:50 +0200, Borislav Petkov wrote:
> On Thu, Jun 26, 2025 at 10:48:47PM +1200, Kai Huang wrote:
> 
> ...
> 
> > Doing WBINVD in stop_this_cpu() could potentially increase the chance to
> > trigger the above "race" despite it's still rare to happen.
> 
> Oh the amount of text... 
> 
> Please run it and all your comments through AI to simplify formulations etc.
> It is a lot to read.

Hi Boris,

Thanks for the comments.

Yeah I agree the text can be improved.  I tried to run AI to simplify but so
far I am not quite happy about the result yet.  I'll try more.

> 
> > Signed-off-by: Kai Huang <kai.huang@...el.com>
> > ---
> >  arch/x86/include/asm/kexec.h         |  2 +-
> >  arch/x86/include/asm/processor.h     |  2 ++
> >  arch/x86/kernel/cpu/amd.c            | 16 ++++++++++++++++
> >  arch/x86/kernel/machine_kexec_64.c   | 15 ++++++++++-----
> >  arch/x86/kernel/process.c            | 16 +++-------------
> >  arch/x86/kernel/relocate_kernel_64.S | 15 +++++++++++----
> >  6 files changed, 43 insertions(+), 23 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> > index f2ad77929d6e..d7e93522b93d 100644
> > --- a/arch/x86/include/asm/kexec.h
> > +++ b/arch/x86/include/asm/kexec.h
> > @@ -122,7 +122,7 @@ relocate_kernel_fn(unsigned long indirection_page,
> >  		   unsigned long pa_control_page,
> >  		   unsigned long start_address,
> >  		   unsigned int preserve_context,
> > -		   unsigned int host_mem_enc_active);
> > +		   unsigned int cache_incoherent);
> 
> So preserve_context and cache_incoherent are both a *single* bit of
> information. And we use two u32s for that?!?!
> 
> How about flags please?

Yeah I agree a single u32 + flags is better.  However this is the problem in
the existing code (this patch only does renaming).

I think I can come up with a patch to clean this up and put it as the first
patch of this series, or I can do a patch to clean this up after this series
(either together with this series, or separately at a later time).  Which
way do you prefer?


> 
> >  #endif
> >  extern relocate_kernel_fn relocate_kernel;
> >  #define ARCH_HAS_KIMAGE_ARCH
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index bde58f6510ac..a24c7805acdb 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -731,6 +731,8 @@ void __noreturn stop_this_cpu(void *dummy);
> >  void microcode_check(struct cpuinfo_x86 *prev_info);
> >  void store_cpu_caps(struct cpuinfo_x86 *info);
> >  
> 
> So much text above - not a single comment here explaining what this var is
> for.

Agreed a comment is needed.  How about below?

  /*
   * The cache may be in an incoherent state (e.g., due to memory 
   * encryption) and needs flushing during kexec.
   */

> 
> > +DECLARE_PER_CPU(bool, cache_state_incoherent);
> > +
> >  enum l1tf_mitigations {
> >  	L1TF_MITIGATION_OFF,
> >  	L1TF_MITIGATION_AUTO,
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index f18f540db58c..4c7fde344216 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -503,6 +503,22 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
> >  {
> >  	u64 msr;
> >  
> > +	/*
> > +	 * Mark using wbinvd is needed during kexec on processors that
> 
> For all text: write insns in caps pls - WBINVD.

Will do.

> 
> > +	 * support SME. This provides support for performing a successful
> > +	 * kexec when going from SME inactive to SME active (or vice-versa).
> > +	 *
> > +	 * The cache must be cleared so that if there are entries with the
> > +	 * same physical address, both with and without the encryption bit,
> > +	 * they don't race each other when flushed and potentially end up
> > +	 * with the wrong entry being committed to memory.
> > +	 *
> > +	 * Test the CPUID bit directly because the machine might've cleared
> > +	 * X86_FEATURE_SME due to cmdline options.
> 
> Where?
> 
> That same function does the clearing later...

IIUC the X86_FEATURE_SME could be cleared via 'clearcpuid' kernel cmdline.

Please also see my reply to Tom.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ