linux-kernel - Re: [PATCH v2] KVM: SVM: let alternatives handle the cases when RSB filling is required

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: <1cd7516391a4c51890c5b0c60a6f149b00cae3af.camel@kernel.org>
Date: Mon, 22 Jul 2024 13:55:49 +0200
From: Amit Shah <amit@...nel.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: David Kaplan <David.Kaplan@....com>, Jim Mattson <jmattson@...gle.com>, 
 "pbonzini@...hat.com" <pbonzini@...hat.com>, "x86@...nel.org"
 <x86@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "tglx@...utronix.de" <tglx@...utronix.de>,  "mingo@...hat.com"
 <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>, 
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "hpa@...or.com" <hpa@...or.com>, Kim Phillips <kim.phillips@....com>
Subject: Re: [PATCH v2] KVM: SVM: let alternatives handle the cases when RSB
 filling is required

On Tue, 2024-07-16 at 12:10 -0700, Sean Christopherson wrote:
> On Mon, Jul 15, 2024, Amit Shah wrote:
> > On (Mon) 08 Jul 2024 [11:59:45], Sean Christopherson wrote:
> > > On Mon, Jul 01, 2024, David Kaplan wrote:
> > > > > > 

(snipped to what is now emerging as the core of the discussion)


> > Also - reviewers of code will get confused, wondering why this code
> > for AMD exists when the CPU vuln does not.
> > 
> > I get that we want to write defensive code, but this was a very
> > special condition that is unlikely to happen in this part of the
> > code,
> > and also this was missed by the devs and the reviewers.
> 
> Defensive code is only part of it, and a minor part at that.  The
> main "issue" is
> having divergent VM-Enter/VM-Exit code for Intel vs. AMD.  To those
> of us that
> care primarily about virtualization and are only passingly familiar
> with the myriad
> speculation bugs and mitigations, omitting RSB_VMEXIT_LITE _looks_
> wrong.
> 
> To know that the omission is correct, one has to suss out that it's
> (supposed to
> be) impossible for RSB_VMEXIT_LITE to be set on AMD.  And as a KVM
> person, that's
> a detail I don't want to care about.

OK - I get that.  Cognitive overload is a real thing, and the less of
it the better.

Since this isn't a discussion about any AMD bug or implementation
detail, but rather a uniformity in KVM code across different CPU
implementations from different vendors, I prefer someone else code up
the patch to add that uniformity.  I don't have an objection to that.

I can of course offer a comment in this hunk, though, that says AMD
does not have the bug that necessitates VMEXIT_LITE, and that should
help in the meantime.  You've not queued this patch yet, right?  Do you
think it's better I do a v3 with this comment update?

> FWIW, I feel the same way about all the other post-VM-Exit
> mitigations, they just
> don't stand out in the same way because the entire mitigation
> sequence is absent
> on one vendor the other, i.e. they don't look wrong at first glance. 
> But if KVM
> could have a mostly unified VM-Enter => VM-Exit assembly code, I
> would happliy eat
> a dead NOP/JMP or three.  Now that I look at it, that actually seems
> very doable...

Sure.  I think some of the fallacy there is also to treat VMX and SVM
as similar (while not treating the Arm side as similar).  They are
different implementations, with several overlapping details - but it's
perilous to think everything maps the same across vendors.


		Amit