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: <CALMp9eR4trBDwgDnyEJmrHnStKnAMiRgehty=xu=NMnLVN2vtw@mail.gmail.com>
Date: Wed, 4 Feb 2026 20:11:57 -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 Wed, Feb 4, 2026 at 5:18 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Wed, Feb 04, 2026, Jim Mattson wrote:
> > On Tue, Feb 3, 2026 at 6:00 PM Sean Christopherson <seanjc@...gle.com> wrote:
> > >
> > > On Thu, Jan 22, 2026, Jim Mattson wrote:
> > > > On Tue, Jan 13, 2026 at 7:47 PM Jim Mattson <jmattson@...gle.com> wrote:
> > > > > 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.
> > >
> > > Eh, running guests with FREEZE_IN_SMM=0 seems absolutely crazy from a security
> > > perspective.  If an admin wants to disable FREEZE_IN_SMM, they get to keep the
> > > pieces.  And KVM definitely isn't going to override the admin, e.g. to allow the
> > > guest to profile host SMM.
> >
> > I'm not sure what you mean by "they get to keep the pieces." What is
> > the security problem with allowing L1 to freeze *guest-owned* PMCs
> > during SMM?
>
> To give L1 the option to freeze PMCs, KVM would also need to give L1 the option
> to *not* freeze PMCs.  At that point, the guest can use its PMCs to profile host
> SMM code.  Maybe even leverage a PMI to attack a poorly written SMM handler.

Perhaps I'm missing something. I was thinking, essentially, of a logical or:

vmcs02.debugctl.freeze_in_smm = vmcs12.debugctl.freeze_in_smm |
vmcs01.debugctl.freeze_in_smm

So, an L1 request to freeze counters in SMM would be granted, but an
L1 request to *not* freeze counters could be overruled by the host.

I'm not suggesting this in the context of the legacy vPMU, because
some PMCs may be counting host-initiated perf events, and L1 should
not have any say in what those PMCs count. However, with the mediated
vPMU, L1 owns the entire PMU while L2 is running, so it seems
reasonable to allow it to freeze the counters during physical SMM.

> In other words, unless I'm missing something, the only reasonable option is to
> run the guest with FREEZE_IN_SMM=1, which means ignoring the guest's wishes.
> Or I guess another way to look at it: you can have any color car you want, as
> long as it's black :-)

I would be happy with FREEZE_IN_SMM=1. I'm not happy with the host
dictating FREEZE_IN_SMM=0.