linux-kernel - Re: [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests

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: <aSXDHq4vUdB8Zqsv@google.com>
Date: Tue, 25 Nov 2025 06:54:22 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Amit Shah <Amit.Shah@....com>
Cc: "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>, "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>, Thomas Lendacky <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>, Babu Moger <Babu.Moger@....com>, 
	Sandipan Das1 <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>, David Kaplan <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 Tue, Nov 25, 2025, Amit Shah wrote:
> On Mon, 2025-11-24 at 16:40 +0000, Andrew Cooper wrote:
> > > > So punting on emulating RAP clearing because it's too hard is not
> > > > an option.  And AFAICT, it's not even that hard.
> > > I didn't mean on punting it in the "it's too hard" sense, but in the
> > > sense that we don't know all the details of when hardware decides to do a
> > > flush; and even if triggers are mentioned in this APM today, future
> > > changes to microcode or APM docs might reveal more triggers that we need
> > > to emulate and account for.  There's no way to track such changes, so my
> > > thinking is that we should be conservative and not assume anything.
> > 
> > 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.
> 
> That's certainly true - that's driving my reluctance to perform the
> emulation or in enabling it for cases that aren't completely clear.

Uh, I think you're misunderstanding what Andrew and I are saying.  Doing nothing
is the worst option.

> > 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".
> 
> To be honest, I haven't seen the mention of those unspecified cases or
> NDA documents.
> 
> However, at least for the case of an NPT guest, the hypervisor does not
> need to do anything special (other than handle nested guests as this
> patch does).

How on earth do you come to that conclusion?  I'm genuinely baffled as to why
you think it's safe to completely ignore RAP clears that are architecturally
supposed to happen from the guest's perspective.