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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYStVN5MyME-Pkwt@google.com>
Date: Thu, 5 Feb 2026 06:47:28 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Jim Mattson <jmattson@...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 04, 2026, Jim Mattson wrote:
> 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.

/facepalm

Sorry, I misunderstood what you were suggesting.  Not sure how, it's super obvious,
at least in hindsight.

> 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.

Agreed.

> > 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.

Yep, make sense.