linux-kernel - Re: [PATCH v2 9/9] KVM: x86: Short-circuit all of kvm_apic_set

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: <ZylSvX4yjYyhVJxC@google.com>
Date: Mon, 4 Nov 2024 15:03:25 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 9/9] KVM: x86: Short-circuit all of kvm_apic_set_base()
 if MSR value is unchanged

On Mon, Nov 04, 2024, Kai Huang wrote:
> On Fri, 2024-11-01 at 11:35 -0700, Sean Christopherson wrote:
> > Do nothing in from kvm_apic_set_base() if the incoming MSR value is the
> > same as the current value, as validating the mode transitions is obviously
> > unnecessary, and rejecting the write is pointless if the vCPU already has
> > an invalid value, e.g. if userspace is doing weird things and modified
> > guest CPUID after setting MSR_IA32_APICBASE.
> > 
> > Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare
> > scenario where the map is DIRTY due to some other vCPU dirtying the map,
> > in which case it's the other vCPU/task's responsibility to recalculate the
> > map.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> > ---
> >  arch/x86/kvm/lapic.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 7b2342e40e4e..59a64b703aad 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -2582,9 +2582,6 @@ static void __kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value)
> >  	u64 old_value = vcpu->arch.apic_base;
> >  	struct kvm_lapic *apic = vcpu->arch.apic;
> >  
> > -	if (old_value == value)
> > -		return;
> > -
> 
> Could you clarify why this is removed?  AFAICT kvm_lapic_reset() still calls
> directly.

It does, but in that case, @old_value is guaranteed to be zero, and @value is
guaranteed to be non-zero, i.e. the check is unnecesary.  At that point, the
check in __kvm_apic_set_base() is 100% dead code, and I think it would do more
harm than good, e.g. might confuse readers.

I thought about adding a WARN, but that seems excessive.

That said, the changelog definitely needs to explain why the check is moved from
__kvm_apic_set_base(), as opposed to another check being added.  How about this?

--
Do nothing in all of kvm_apic_set_base(), not just __kvm_apic_set_base(),
if the incoming MSR value is the same as the current value.  Validating
the mode transitions is obviously unnecessary, and rejecting the write is
pointless if the vCPU already has an invalid value, e.g. if userspace is
doing weird things and modified guest CPUID after setting MSR_IA32_APICBASE.

Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare
scenario where the map is DIRTY due to some other vCPU dirtying the map,
in which case it's the other vCPU/task's responsibility to recalculate the
map.

Note, kvm_lapic_reset() calls __kvm_apic_set_base() only when emulating
RESET, in which case the old value is guaranteed to be zero, and the new
value is guaranteed to be non-zero.  I.e. all callers of
__kvm_apic_set_base() effectively pre-check for the MSR value actually
changing.  Don't bother keeping the check in __kvm_apic_set_base(), as no
additional callers are expected, and implying that the MSR might already
be non-zero at the time of kvm_lapic_reset() could confuse readers.
--