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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <08826b5879e2d9c354424279763d3ce5556f44cc.camel@amd.com>
Date: Thu, 11 Dec 2025 16:09:06 +0000
From: "Shah, Amit" <Amit.Shah@....com>
To: "seanjc@...gle.com" <seanjc@...gle.com>, "andrew.cooper3@...rix.com"
	<andrew.cooper3@...rix.com>
CC: "corbet@....net" <corbet@....net>, "pawan.kumar.gupta@...ux.intel.com"
	<pawan.kumar.gupta@...ux.intel.com>, "kai.huang@...el.com"
	<kai.huang@...el.com>, "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>, "Lendacky,
 Thomas" <Thomas.Lendacky@....com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "Moger,
 Babu" <Babu.Moger@....com>, "Das1, Sandipan" <Sandipan.Das@....com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "hpa@...or.com"
	<hpa@...or.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"bp@...en8.de" <bp@...en8.de>, "boris.ostrovsky@...cle.com"
	<boris.ostrovsky@...cle.com>, "Kaplan, David" <David.Kaplan@....com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests

On Mon, 2025-11-24 at 16:40 +0000, Andrew Cooper wrote:


[...]

> But this *is* the problem.  The APM says that OSes can depend on this
> property for safety, and does not provide enough information for
> Hypervisors to make it safe.
> 
> ERAPS is a bad spec.  It should not have gotten out of the door.
> 
> A better spec would say "clears the RAP on any MOV to CR3" and
> nothing else.
> 
> The fact that it might happen microarchitecturally in other cases
> doesn't matter; what matters is what OSes can architecturally depend
> on,
> and right now that that explicitly includes "unspecified cases in NDA
> documents".

I'd like to clarify and confirm the details around TLB flushes and
their effects of ERAPS here as an official AMD statement. First, I'd
like to clarify that INVLPGB does not flush the RAP.

Second,

Referring to the APM at

https://docs.amd.com/v/u/en-US/24593_3.43

Section 3.2.9: move to CR3 and the execution of INVPCID are the
instructions that result in the flushing of the ERAPS.

The reference to section 5.3.3 - TLB Management - and the implicit TLB
flushes there was unclear which led to most of the speculation in this
discussion earlier in this thread.  For the section 5.3.3, we will
update the APM to clarify that the "writes to certain MSRs" relates to
microarchitectural behavior.

The updated wording for section 5.3.3 will make its way in a future APM
update.

(For the curious, the list of those MSRs currently is APIC_BASE,
PREFETCH_CONTROL, SYSCFG, IORRs, TOM/TOM2, SMMADDR/MASK, ECS_BASE, but
of course this is subject to change.)

Coming back to the patch here with these clarifications from AMD
architects - I am happy with Sean's update to the patch.  I've also
tested the patch and it works as expected on a Zen5 CPU.

Reviewed-by: Amit Shah <amit.shah@....com>

Thanks,

		Amit

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ