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]
Date: Wed, 5 Jun 2024 17:08:01 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, pbonzini@...hat.com, thomas.lendacky@....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,
 ravi.bangoria@....com
Subject: Re: [PATCH 3/3] KVM SVM: Add Bus Lock Detect support

Hi Sean,

On 6/4/2024 6:15 AM, Sean Christopherson wrote:
> On Mon, Apr 29, 2024, Ravi Bangoria wrote:
>> Upcoming AMD uarch will support Bus Lock Detect. Add support for it
>> in KVM. Bus Lock Detect is enabled through MSR_IA32_DEBUGCTLMSR and
>> MSR_IA32_DEBUGCTLMSR is virtualized only if LBR Virtualization is
>> enabled. Add this dependency in the KVM.
> 
> This is woefully incomplete, e.g. db_interception() needs to be updated to decipher
> whether the #DB is the responsbility of the host or of the guest.

Can you please elaborate. Are you referring to vcpu->guest_debug thingy?

> Honestly, I don't see any point in virtualizing this in KVM.  As Jim alluded to,
> what's far, far more interesting for KVM is "Bus Lock Threshold".  Virtualizing
> this for the guest would have been nice to have during the initial split-lock #AC
> support, but now I'm skeptical the complexity is worth the payoff.

This has a valid usecase of penalizing offending processes. I'm not sure
how much it's really used in the production though.

> I suppose we could allow it if #DB isn't interecepted, at which point the enabling
> required is minimal?

The feature uses DEBUG_CTL MSR, #DB and DR6 register. Do you mean expose
it when all three are accelerated or just #DB?

Thanks for the feedback,
Ravi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ