linux-kernel - Re: [PATCH v4 4/4] KVM: SVM: Add Bus Lock Detect support

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: <ZszKCCXE7yT4zCEd@google.com>
Date: Mon, 26 Aug 2024 11:31:36 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, pbonzini@...hat.com, thomas.lendacky@....com, 
	jmattson@...gle.com, hpa@...or.com, rmk+kernel@...linux.org.uk, 
	peterz@...radead.org, james.morse@....com, lukas.bulwahn@...il.com, 
	arjan@...ux.intel.com, j.granados@...sung.com, sibs@...natelecom.cn, 
	nik.borisov@...e.com, michael.roth@....com, nikunj.dadhania@....com, 
	babu.moger@....com, x86@...nel.org, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, santosh.shukla@....com, ananth.narayan@....com, 
	sandipan.das@....com, manali.shukla@....com
Subject: Re: [PATCH v4 4/4] KVM: SVM: Add Bus Lock Detect support

On Wed, Aug 21, 2024, Ravi Bangoria wrote:
> On 21-Aug-24 11:06 AM, Ravi Bangoria wrote:
> >>> @@ -3158,6 +3159,10 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
> >>>  		if (data & DEBUGCTL_RESERVED_BITS)
> >>
> >> Not your code, but why does DEBUGCTL_RESERVED_BITS = ~0x3f!?!?  That means the
> >> introduction of the below check, which is architecturally correct, has the
> >> potential to break guests.  *sigh*
> >>
> >> I doubt it will cause a problem, but it's something to look out for.
> > This dates back to 2008: https://git.kernel.org/torvalds/c/24e09cbf480a7
> > 
> > The legacy definition[1] of DEBUGCTL MSR is:
> > 
> >   5:2   PB: performance monitor pin control. Read-write. Reset: 0h.
> >         This field does not control any hardware.

Uh, what?  So the CPU provided 4 bits of scratch space?  Or is that saying that
5:2 controlled some perfmon stuff on older CPUs, but that Zen deprecated those
bits?

> >   1     BTF. Read-write. Reset: 0. 1=Enable branch single step.
> >   0     LBR. Read-write. Reset: 0. 1=Enable last branch record.
> > 
> > [1]: https://bugzilla.kernel.org/attachment.cgi?id=287389
> 
> How about adding cpu_feature_enabled() check:

That doesn't fix anything, KVM will still break, just on a smaller set of CPUs.

The only way to avoid breaking guests is to ignore bits 5:2, though we could
quirk that so that userspace can effectively enable what is now the architectural
behavior.

Though I'm very tempted to just add a prep patch to disallow setting bits 5:2 and
see if anyone complains.  If they do, then we can add a quirk.  And if no one
complains, yay.