linux-kernel - Re: [PATCH] KVM: VMX: Add quirk to allow L1 to set FREEZE_IN

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: <CALMp9eTYakMk0Bogxa_GdGU5_h4PK-YOXcu-cSQ16m1QcusHxw@mail.gmail.com>
Date: Tue, 13 Jan 2026 19:47:58 -0800
From: Jim Mattson <jmattson@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Jonathan Corbet <corbet@....net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: VMX: Add quirk to allow L1 to set FREEZE_IN_SMM in vmcs12

On Tue, Jan 13, 2026 at 4:42 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Tue, Jan 13, 2026, Jim Mattson wrote:
> > Add KVM_X86_QUIRK_VMCS12_FREEZE_IN_SMM to allow L1 to set
> > IA32_DEBUGCTL.FREEZE_IN_SMM in vmcs12 when using nested VMX.  Prior to
> > commit 6b1dd26544d0 ("KVM: VMX: Preserve host's
> > DEBUGCTLMSR_FREEZE_IN_SMM while running the guest"), L1 could set
> > FREEZE_IN_SMM in vmcs12 to freeze PMCs during physical SMM coincident
> > with L2's execution.  The quirk is enabled by default for backwards
> > compatibility; userspace can disable it via KVM_CAP_DISABLE_QUIRKS2 if
> > consistency with WRMSR(IA32_DEBUGCTL) is desired.
>
> It's probably worth calling out that KVM will still drop FREEZE_IN_SMM in vmcs02
>
>         if (vmx->nested.nested_run_pending &&
>             (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS)) {
>                 kvm_set_dr(vcpu, 7, vmcs12->guest_dr7);
>                 vmx_guest_debugctl_write(vcpu, vmcs12->guest_ia32_debugctl &
>                                                vmx_get_supported_debugctl(vcpu, false)); <====
>         } else {
>                 kvm_set_dr(vcpu, 7, vcpu->arch.dr7);
>                 vmx_guest_debugctl_write(vcpu, vmx->nested.pre_vmenter_debugctl);
>         }
>
> both from a correctness standpoint and so that users aren't mislead into thinking
> the quirk lets L1 control of FREEZE_IN_SMM while running L2.

Yes, it's probably worth pointing out that the VM is now subject to
the whims of the L0 administrators.

While that makes some sense for the legacy vPMU, where KVM is just
another client of host perf, perhaps the decision should be revisited
in the case of the MPT vPMU, where KVM owns the PMU while the vCPU is
in VMX non-root operation.

> > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> > index 0521b55d47a5..bc8f0b3aa70b 100644
> > --- a/arch/x86/kvm/vmx/nested.c
> > +++ b/arch/x86/kvm/vmx/nested.c
> > @@ -3298,10 +3298,24 @@ static int nested_vmx_check_guest_state(struct kvm_vcpu *vcpu,
> >       if (CC(vmcs12->guest_cr4 & X86_CR4_CET && !(vmcs12->guest_cr0 & X86_CR0_WP)))
> >               return -EINVAL;
> >
> > -     if ((vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS) &&
> > -         (CC(!kvm_dr7_valid(vmcs12->guest_dr7)) ||
> > -          CC(!vmx_is_valid_debugctl(vcpu, vmcs12->guest_ia32_debugctl, false))))
> > -             return -EINVAL;
> > +     if (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS) {
> > +             u64 debugctl = vmcs12->guest_ia32_debugctl;
> > +
> > +             /*
> > +              * FREEZE_IN_SMM is not virtualized, but allow L1 to set it in
> > +              * L2's DEBUGCTL under a quirk for backwards compatibility.
> > +              * Prior to KVM taking ownership of the bit to ensure PMCs are
> > +              * frozen during physical SMM, L1 could set FREEZE_IN_SMM in
> > +              * vmcs12 to freeze PMCs during physical SMM coincident with
> > +              * L2's execution.
> > +              */
> > +             if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_VMCS12_FREEZE_IN_SMM))
> > +                     debugctl &= ~DEBUGCTLMSR_FREEZE_IN_SMM;
> > +
> > +             if (CC(!kvm_dr7_valid(vmcs12->guest_dr7)) ||
> > +                 CC(!vmx_is_valid_debugctl(vcpu, debugctl, false)))
>
> I'm mildly tempted to say we should quirk the entire consistency check instead of
> limiting it to FREEZE_IN_SMM, purely so that we don't have to add yet another quirk
> if a different setup breaks on a different bit.  I suppose we could limit the quirk
> to bits that could have been plausibly set in hardware, because otherwise VM-Entry
> using L2 would VM-Fail, but that's still quite a few bits.
>
> I'm definitely not opposed to a targeted quirk though.

I have no preference.

> > +                     return -EINVAL;
> > +     }
> >
> >       if ((vmcs12->vm_entry_controls & VM_ENTRY_LOAD_IA32_PAT) &&
> >           CC(!kvm_pat_valid(vmcs12->guest_ia32_pat)))
> > --
> > 2.52.0.457.g6b5491de43-goog
> >