| Message ID | 20250227222411.3490595-1-seanjc@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: SVM: Fix DEBUGCTL bugs | expand |
On 28-Feb-25 3:54 AM, Sean Christopherson wrote: > Fix a long-lurking bug in SVM where KVM runs the guest with the host's > DEBUGCTL if LBR virtualization is disabled. AMD CPUs rather stupidly > context switch DEBUGCTL if and only if LBR virtualization is enabled (not > just supported, but fully enabled). > > The bug has gone unnoticed because until recently, the only bits that > KVM would leave set were things like BTF, which are guest visible but > won't cause functional problems unless guest software is being especially > particular about #DBs. > > The bug was exposed by the addition of BusLockTrap ("Detect" in the kernel), > as the resulting #DBs due to split-lock accesses in guest userspace (lol > Steam) get reflected into the guest by KVM. > > Note, I don't love suppressing DEBUGCTL.BTF, but practically speaking that's > likely the behavior that SVM guests have gotten the vast, vast majority of > the time, and given that it's the behavior on Intel, it's (hopefully) a safe > option for a fix, e.g. versus trying to add proper BTF virtualization on the > fly. > > v3: > - Suppress BTF, as KVM doesn't actually support it. [Ravi] > - Actually load the guest's DEBUGCTL (though amusingly, with BTF squashed, > it's guaranteed to be '0' in this scenario). [Ravi] > > v2: > - Load the guest's DEBUGCTL instead of simply zeroing it on VMRUN. > - Drop bits 5:3 from guest DEBUGCTL so that KVM doesn't let the guest > unintentionally enable BusLockTrap (AMD repurposed bits). [Ravi] > - Collect a review. [Xiaoyao] > - Make bits 5:3 fully reserved, in a separate not-for-stable patch. > > v1: https://lore.kernel.org/all/20250224181315.2376869-1-seanjc@google.com For the series, Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com> Thanks, Ravi
On Fri, Feb 28, 2025, Ravi Bangoria wrote: > On 28-Feb-25 3:54 AM, Sean Christopherson wrote: > > Fix a long-lurking bug in SVM where KVM runs the guest with the host's > > DEBUGCTL if LBR virtualization is disabled. AMD CPUs rather stupidly > > context switch DEBUGCTL if and only if LBR virtualization is enabled (not > > just supported, but fully enabled). > > > > The bug has gone unnoticed because until recently, the only bits that > > KVM would leave set were things like BTF, which are guest visible but > > won't cause functional problems unless guest software is being especially > > particular about #DBs. > > > > The bug was exposed by the addition of BusLockTrap ("Detect" in the kernel), > > as the resulting #DBs due to split-lock accesses in guest userspace (lol > > Steam) get reflected into the guest by KVM. > > > > Note, I don't love suppressing DEBUGCTL.BTF, but practically speaking that's > > likely the behavior that SVM guests have gotten the vast, vast majority of > > the time, and given that it's the behavior on Intel, it's (hopefully) a safe > > option for a fix, e.g. versus trying to add proper BTF virtualization on the > > fly. > > > > v3: > > - Suppress BTF, as KVM doesn't actually support it. [Ravi] > > - Actually load the guest's DEBUGCTL (though amusingly, with BTF squashed, > > it's guaranteed to be '0' in this scenario). [Ravi] > > > > v2: > > - Load the guest's DEBUGCTL instead of simply zeroing it on VMRUN. > > - Drop bits 5:3 from guest DEBUGCTL so that KVM doesn't let the guest > > unintentionally enable BusLockTrap (AMD repurposed bits). [Ravi] > > - Collect a review. [Xiaoyao] > > - Make bits 5:3 fully reserved, in a separate not-for-stable patch. > > > > v1: https://lore.kernel.org/all/20250224181315.2376869-1-seanjc@google.com > > For the series, > > Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com> Thank you for all your help, much appreciated!
On Thu, 27 Feb 2025 14:24:05 -0800, Sean Christopherson wrote: > Fix a long-lurking bug in SVM where KVM runs the guest with the host's > DEBUGCTL if LBR virtualization is disabled. AMD CPUs rather stupidly > context switch DEBUGCTL if and only if LBR virtualization is enabled (not > just supported, but fully enabled). > > The bug has gone unnoticed because until recently, the only bits that > KVM would leave set were things like BTF, which are guest visible but > won't cause functional problems unless guest software is being especially > particular about #DBs. > > [...] Applied 1-5 to kvm-x86 fixes (for 6.14). I'm going to hold off on making DEBUGCTL[5:2] reserved until at least 6.15. [1/6] KVM: SVM: Drop DEBUGCTL[5:2] from guest's effective value https://github.com/kvm-x86/linux/commit/ee89e8013383 [2/6] KVM: SVM: Suppress DEBUGCTL.BTF on AMD https://github.com/kvm-x86/linux/commit/d0eac42f5cec [3/6] KVM: x86: Snapshot the host's DEBUGCTL in common x86 https://github.com/kvm-x86/linux/commit/fb71c7959356 [4/6] KVM: SVM: Manually context switch DEBUGCTL if LBR virtualization is disabled https://github.com/kvm-x86/linux/commit/433265870ab3 [5/6] KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs https://github.com/kvm-x86/linux/commit/189ecdb3e112 [6/6] KVM: SVM: Treat DEBUGCTL[5:2] as reserved (no commit info) -- https://github.com/kvm-x86/linux/tree/next
Fix a long-lurking bug in SVM where KVM runs the guest with the host's DEBUGCTL if LBR virtualization is disabled. AMD CPUs rather stupidly context switch DEBUGCTL if and only if LBR virtualization is enabled (not just supported, but fully enabled). The bug has gone unnoticed because until recently, the only bits that KVM would leave set were things like BTF, which are guest visible but won't cause functional problems unless guest software is being especially particular about #DBs. The bug was exposed by the addition of BusLockTrap ("Detect" in the kernel), as the resulting #DBs due to split-lock accesses in guest userspace (lol Steam) get reflected into the guest by KVM. Note, I don't love suppressing DEBUGCTL.BTF, but practically speaking that's likely the behavior that SVM guests have gotten the vast, vast majority of the time, and given that it's the behavior on Intel, it's (hopefully) a safe option for a fix, e.g. versus trying to add proper BTF virtualization on the fly. v3: - Suppress BTF, as KVM doesn't actually support it. [Ravi] - Actually load the guest's DEBUGCTL (though amusingly, with BTF squashed, it's guaranteed to be '0' in this scenario). [Ravi] v2: - Load the guest's DEBUGCTL instead of simply zeroing it on VMRUN. - Drop bits 5:3 from guest DEBUGCTL so that KVM doesn't let the guest unintentionally enable BusLockTrap (AMD repurposed bits). [Ravi] - Collect a review. [Xiaoyao] - Make bits 5:3 fully reserved, in a separate not-for-stable patch. v1: https://lore.kernel.org/all/20250224181315.2376869-1-seanjc@google.com Sean Christopherson (6): KVM: SVM: Drop DEBUGCTL[5:2] from guest's effective value KVM: SVM: Suppress DEBUGCTL.BTF on AMD KVM: x86: Snapshot the host's DEBUGCTL in common x86 KVM: SVM: Manually context switch DEBUGCTL if LBR virtualization is disabled KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs KVM: SVM: Treat DEBUGCTL[5:2] as reserved arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/svm/svm.c | 24 ++++++++++++++++++++++++ arch/x86/kvm/svm/svm.h | 2 +- arch/x86/kvm/vmx/vmx.c | 8 ++------ arch/x86/kvm/vmx/vmx.h | 2 -- arch/x86/kvm/x86.c | 2 ++ 6 files changed, 30 insertions(+), 9 deletions(-) base-commit: fed48e2967f402f561d80075a20c5c9e16866e53