From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 754601F5842 for ; Thu, 5 Feb 2026 01:18:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770254282; cv=none; b=EVbBtl+CsWzHf6UfkkLJZw88p04B73lSltNXX3WHndhD/fUJBw85m7vq9DEVSnXC5CW5iCzAig03VFVmGZrOBeulGFWfrxGhrkXtJcA7EPpkMVDfyA4TCaD1rcOFtTgkTm80vP9atccW9DCH1uhvy6IHlGI498/+GjpGoDb/IOk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770254282; c=relaxed/simple; bh=weq0fqo2tPGc5lpeGNhlb77TCji/77VOUp62fcKvqNw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=rpixtcddCqN//ygzn44H1mtKc8BdWSoDF8sBGgqIMjU1QceN9yZscB1NReS8cr/1YX526K5fOzUc+0hv/i9vmKvYY6JpM97LxvbNorZHfIf6PP7pJcvr1ZQXJHqX+PCtBHT20qrDll7W1RFUHlSfEz3y7eokavIX+NtHkkkRlmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=s8gVOT6c; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="s8gVOT6c" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2a377e15716so10770125ad.3 for ; Wed, 04 Feb 2026 17:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770254282; x=1770859082; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=pyiDI7VPKF7gTzcDOmb56BEbcPVZQnYwftAUhlr4O+0=; b=s8gVOT6ck0bPDE/tbb8L/MwBtZMIMjxWAULn00IJa9BplzYLQDAGklmUDZtpw4n90j VIxN1rxGheF76p0kHf33zdDDknuqGZMHqOJvAKT8tipnFZNj+1ZB7bRu8f2ysIPP8oQp jYbKLBNOS2U84NUL+mfhPY98CUyPHaBGXzK7+1cr4pMXt1f0xbbZqhmUT9/Q3oCKNjF+ kXu7ljvm55nJ03lJCaOZkQk+5MluC/ZWr7vsMeGvmx9Et77LYcW4cdM3XIjct3yWfWuJ Q5jGfSmjbdrDVk+dh1n97/8XBF4iHk9N8lXw5gP5QSiq+dUlP75e9I6Xy6btx6RqJFWw dsAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770254282; x=1770859082; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=pyiDI7VPKF7gTzcDOmb56BEbcPVZQnYwftAUhlr4O+0=; b=GSi/Q5UM5TRmSgNBuib1a5pHP9A5BmNXig2ucVBES/FgS7sZYgUHG7zKDJCzOT3SXp dxU9VKwSz07U8AAQMlLP5M+q8JTdPLfWtcGd8tJrTFY4KRxivGggFJdisSsR+D3wnY4M GZzWm3nanTrLgF2FcJcu9QfzbSCX2aEgr4I/iUlyxnoJyPwmtX3EtC4wRjrInQQiP4ri 9LXklnsB39+wRnBu0BthH5OHL+g/KrwjXRGC+VCk2UyQl8ZQ9AQ2aleHo7eotAIMkMhN 3V3NW16MA6MOD+ONZzMjRtxM4vRZoMvP/teBmhsc0/yNjWoHh57lsu74BhnXwGAy8o+z JuyA== X-Forwarded-Encrypted: i=1; AJvYcCWRibS6Gw/Sh966OeJoNEkMleTw6hQToaKWi2/VdulusJcXATi3eVnapLrDQmzeq4tWK6AUJAMe5fZ25V8=@vger.kernel.org X-Gm-Message-State: AOJu0YzJHVC4layOEuxl4JkcRpgusdm5wbSPbmVn9iTA66CWOTOBtRzP 2gLcNfvIY/tZWwt2Yu3s3HHYNlamh63nfPfNThfd0UDZkIlTXrSvpDxSIMcm8Ynn/WjBN81Gwtv rUjgwBw== X-Received: from pjva13.prod.google.com ([2002:a17:90a:d80d:b0:352:d931:fa5b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:a108:b0:393:7575:a8be with SMTP id adf61e73a8af0-3937575c9d5mr3614095637.68.1770254281643; Wed, 04 Feb 2026 17:18:01 -0800 (PST) Date: Wed, 4 Feb 2026 17:18:00 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260113225406.273373-1-jmattson@google.com> Message-ID: Subject: Re: [PATCH] KVM: VMX: Add quirk to allow L1 to set FREEZE_IN_SMM in vmcs12 From: Sean Christopherson To: Jim Mattson Cc: Paolo Bonzini , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Maxim Levitsky , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2026, Jim Mattson wrote: > On Tue, Feb 3, 2026 at 6:00=E2=80=AFPM Sean Christopherson wrote: > > > > On Thu, Jan 22, 2026, Jim Mattson wrote: > > > On Tue, Jan 13, 2026 at 7:47=E2=80=AFPM Jim Mattson wrote: > > > > On Tue, Jan 13, 2026 at 4:42=E2=80=AFPM Sean Christopherson 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. P= rior to > > > > > > commit 6b1dd26544d0 ("KVM: VMX: Preserve host's > > > > > > DEBUGCTLMSR_FREEZE_IN_SMM while running the guest"), L1 could s= et > > > > > > FREEZE_IN_SMM in vmcs12 to freeze PMCs during physical SMM coin= cident > > > > > > with L2's execution. The quirk is enabled by default for backw= ards > > > > > > compatibility; userspace can disable it via KVM_CAP_DISABLE_QUI= RKS2 if > > > > > > consistency with WRMSR(IA32_DEBUGCTL) is desired. > > > > > > > > > > It's probably worth calling out that KVM will still drop FREEZE_I= N_SMM in vmcs02 > > > > > > > > > > if (vmx->nested.nested_run_pending && > > > > > (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONT= ROLS)) { > > > > > kvm_set_dr(vcpu, 7, vmcs12->guest_dr7); > > > > > vmx_guest_debugctl_write(vcpu, vmcs12->guest_ia32= _debugctl & > > > > > vmx_get_supported_= debugctl(vcpu, false)); <=3D=3D=3D=3D > > > > > } else { > > > > > kvm_set_dr(vcpu, 7, vcpu->arch.dr7); > > > > > vmx_guest_debugctl_write(vcpu, vmx->nested.pre_vm= enter_debugctl); > > > > > } > > > > > > > > > > both from a correctness standpoint and so that users aren't misle= ad 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 revisit= ed > > > > 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=3D0 seems absolutely crazy from a= security > > perspective. If an admin wants to disable FREEZE_IN_SMM, they get to k= eep the > > pieces. And KVM definitely isn't going to override the admin, e.g. to = allow the > > guest to profile host SMM. >=20 > 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 op= tion 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= . In other words, unless I'm missing something, the only reasonable option is= to run the guest with FREEZE_IN_SMM=3D1, which means ignoring the guest's wish= es. Or I guess another way to look at it: you can have any color car you want, = as long as it's black :-)=20