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] [day] [month] [year] [list]

Message-ID: <ZuB8j02laOrxq-ji@google.com>
Date: Tue, 10 Sep 2024 10:06:23 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Amit Shah <amit@...nel.org>
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 Mon, Jul 22, 2024, Amit Shah wrote:
> On Tue, 2024-07-16 at 12:10 -0700, Sean Christopherson wrote:
> > 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).

Bringing ARM into the picture is little more than whataboutism.  KVM x86 and KVM
arm64 _can't_ share assembly.  They _can't_ share things like MSR interception
tracking because MSRs are 100% an x86-only concept.  The fact that sharing code
across x86 and ARM is challenging doesn't have any bearing on whether or not
VMX and SVM can/should share code.

> They are different implementations, with several overlapping details - but
> it's perilous to think everything maps the same across vendors.

I never said everything maps the same.  The point I am trying to make is that
there is significant value _for KVM_ in having common code between architectures,
and between vendors within an architecture.  I can provide numerous examples
where something was implemented/fixed in vendor/arch code, and then later it was
discovered that the feature/fix was also wanted/needed in other vendor/arch code.