From nobody Wed Apr 8 04:39:43 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 2C7633CAE89 for ; Tue, 10 Mar 2026 23:49:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773186543; cv=none; b=ZSaisqPbzw6A7L9Y6tYeLlftPyiph1p+wvoa8zvIfzGqcdcJDGivawOnAaf4GLmxoTid8sSRGAKO737jCRNwoizcdodasaTIaMZ+i+zFBScc+oWE3ktYb4l06owobBw/oaRhFbA2ydPPXBPNYjZvLOfL25vDR/4B2vEegxhXbTg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773186543; c=relaxed/simple; bh=uVoR9Xe4mRfHE6loxSVhvjcSNc6aBMfQ8wHKJPqrrOc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Eu8us8ie3/OJ+BMK6GsS572i7bi/WIjCBQ7Pvz2h5g93dYBR/ggXaD0HL4gIoZ+EnW1eIcYC3wh2bWggQlyMg0vYao96WqRIGSKBtn86EoImxeOOR6gAj3i2nmetJlyn7OrGxPvesLLphjRcrBAEL299c+VlcsYzB0tSfrRK4Kc= 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=j0n9jp7h; arc=none smtp.client-ip=209.85.216.74 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="j0n9jp7h" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-359f31809a0so6436236a91.2 for ; Tue, 10 Mar 2026 16:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773186541; x=1773791341; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=gENHh+LHHspcmPyJqV4yOmmwYVieLWgsYWBJG3PvZfE=; b=j0n9jp7hWsJEOfwS46O4qU5dAFnw1Ded1NVV1k1Co0N5SebsGDwWPE4wlsMXfSgsuK LHFSadnR4VJuJXJDqD1mOADzwtUp1A0ZSXS3FBLZz/+6TAeBx9yElMEcTOJAoAijDYRj 9KzJr2VfDwiJY6tu6Zf17LRswD4MPFY7wULU+AGVNJuZHXX1O47QVABXLcu/D/EeibgM VclmVIZUnlzakmTeYOoRiZoPRgmE1rpKZ7HbF8VEmSB6HMIlKWF6NtuCRNSih/JyrbUz rYNbKu1YlJLbL9907i/cUX0qa+dMqaKjtvv1Agva9YhQ/TTKzMUi+VywefHakOlmA6kQ 5lVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773186541; x=1773791341; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gENHh+LHHspcmPyJqV4yOmmwYVieLWgsYWBJG3PvZfE=; b=O+HsBCKBmyRmwdizOL6SOxU15BhVi9ZWTxlq/zqpmPSd0+WH3JJ8Hzska+tduTqQX3 0kVIF1Vs4GmE+BmiIvrBtdVd9gKtybdXmOBwx93ASyXTmzq22RNnsi3p+FAGYArSa4L9 g2PL7p3HmPIZHyiE2ovL0COzkX4NSZj5E0Sh9x8ng0e2qaGa9AZfK7WDKhGjP2EzYK6S zGABVLzHtTvJpD9mtPSRL+dvorhl4mBEXmW8H0chzHjvn1q0eRxFtGb2KBO1mCUD5+zS RQginHJZtpLtYufenFwY+cCEPRTqwnkOoJRQMR3XWLEJb4ih1yd+uj34r/WZlkD2txmv NyDA== X-Forwarded-Encrypted: i=1; AJvYcCVNcsLC01j4ClEHPsQl9oKteZXjbY+ubPu7CotDvQD57UfcyFa3u4zW13SDYj1ObhIsN7VfB89GRwdelMI=@vger.kernel.org X-Gm-Message-State: AOJu0YzKVMrQkLfE8I4hkPfYnUMhVghURWtmBYDkcqUXL8Ba/dgYf3u7 wOMyU98lV6dsTaQLw3ecpk1DGb04Ze9dzHXltNBvs3ph3nGS8NoIk8bnx5toW9NIMT6AN3Uw96m hP5Ogeg== X-Received: from pjbbx13.prod.google.com ([2002:a17:90a:f48d:b0:359:f1f1:7bcb]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5743:b0:34c:fe57:2793 with SMTP id 98e67ed59e1d1-35a0138a096mr508515a91.20.1773186541445; Tue, 10 Mar 2026 16:49:01 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 10 Mar 2026 16:48:23 -0700 In-Reply-To: <20260310234829.2608037-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260310234829.2608037-1-seanjc@google.com> X-Mailer: git-send-email 2.53.0.473.g4a7958ca14-goog Message-ID: <20260310234829.2608037-16-seanjc@google.com> Subject: [PATCH 15/21] KVM: SEV: Assert that kvm->lock is held when querying SEV+ support From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jethro Beekman , Alexander Potapenko , "=?UTF-8?q?Carlos=20L=C3=B3pez?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Assert that kvm->lock is held when checking if a VM is an SEV+ VM, as KVM sets *and* resets the relevant flags when initialization SEV state, i.e. it's extremely easy to end up with TOCTOU bugs if kvm->lock isn't held. Add waivers for a VM being torn down (refcount is '0') and for there being a loaded vCPU, with comments for both explaining why they're safe. Note, the "vCPU loaded" waiver is necessary to avoid splats on the SNP checks in sev_gmem_prepare() and sev_gmem_max_mapping_level(), which are currently called when handling nested page faults. Alternatively, those checks could key off KVM_X86_SNP_VM, as kvm_arch.vm_type is stable early in VM creation. Prioritize consistency, at least for now, and to leave a "reminder" that the max mapping level code in particular likely needs special attention if/when KVM supports dirty logging for SNP guests. Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 7bb9318f0703..cbb5886304fa 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -107,17 +107,42 @@ static unsigned int nr_asids; static unsigned long *sev_asid_bitmap; static unsigned long *sev_reclaim_asid_bitmap; =20 +static __always_inline void kvm_lockdep_assert_sev_lock_held(struct kvm *k= vm) +{ +#ifdef CONFIG_PROVE_LOCKING + /* + * Querying SEV+ support is safe if there are no other references, i.e. + * if concurrent initialization of SEV+ is impossible. + */ + if (!refcount_read(&kvm->users_count)) + return; + + /* + * Querying SEV+ support from vCPU context is always safe, as vCPUs can + * only be created after SEV+ is initialized (and KVM disallows all SEV + * sub-ioctls while vCPU creation is in-progress). + */ + if (kvm_get_running_vcpu()) + return; + + lockdep_assert_held(&kvm->lock); +#endif +} + static bool sev_guest(struct kvm *kvm) { + kvm_lockdep_assert_sev_lock_held(kvm); return ____sev_guest(kvm); } static bool sev_es_guest(struct kvm *kvm) { + kvm_lockdep_assert_sev_lock_held(kvm); return ____sev_es_guest(kvm); } =20 static bool sev_snp_guest(struct kvm *kvm) { + kvm_lockdep_assert_sev_lock_held(kvm); return ____sev_snp_guest(kvm); } =20 --=20 2.53.0.473.g4a7958ca14-goog