From mboxrd@z Thu Jan 1 00:00:00 1970 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 69113346FB8 for ; Thu, 30 Oct 2025 20:11:06 +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=1761855068; cv=none; b=IHgEVDr1jUBahkmOv7tZ24eRgj7czSJIZ9zVpBHbcehnOsLOlHHkLV6yvEBLdF5L099E4iIkMugt3EGr8+KOEEWQNKhncFeQ4ixLHDKocGkEEn6ec+TXPsHZXvBd0iKjBosOqiQMP0NuZ+8dstlkRt+dK0JvrS7aIQ28doI9mOs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761855068; c=relaxed/simple; bh=BNSOEKa28oWXqKHW7RuSRcfta2Y9XobgHdriosWTdaA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=RmLmG1ZT5jliKMMz5I1/Y5hkOLGViE/np4GZipEGsPfCk7Ieq5gTU3JKnogokUMTaF5LhAYNgv36Dxq7SOPF5/pd2+MW1WIQIz2uEgCgHOINMIrYmj6YKutzWn1SBu62vO4JKU4zJqSaGyYjDriAG9pETov5RyqXf6KW+DY79mY= 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=RPIJ4nHR; 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="RPIJ4nHR" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-32ee4998c50so1121917a91.3 for ; Thu, 30 Oct 2025 13:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1761855066; x=1762459866; darn=lists.linux.dev; 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=gJtCncfCK9X54oXx991KGpYhmmpTyjjcLT5mmtOhZeY=; b=RPIJ4nHRQuSGjKmfTH1q82V7HreeAbYj76RwoXssQAGn76ZmBqzJ+GoWdGJyEeAQtR 05RW9NOAJ6g6YGl0BZVOWr3NEdn8vgcY7mKThWQiXJPlCeok61Ej6unDjb6DB3XHlt/P rcuHfjKma5aSSOPXDFgFms9xqTjSyNL2/KD9ea+Kd6bUtbrjcWG4FaIg5+imIzymDM/H 2vPktDZgbNiiyxGVz0VpJM6A4JcZrotIrUVmQ+RnxTxuyIWgXwBQNKtd0hi689iZi2rG pmPbTnjk8cezIrsQYKOxj5qubi7C0lvoUcX4uR1p/Wdehul0v94p3C3zU96BBWOV0qWg pAJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761855066; x=1762459866; 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=gJtCncfCK9X54oXx991KGpYhmmpTyjjcLT5mmtOhZeY=; b=FDDxBwcjH1w8tJ4Xw+9TUZe9nG3d4xERBr6t4r3p3Cq19vt7eVA9Drhks/SO17/Vl5 +NZia2VR9EfyD9j7yycYC65nWhBhVZ3HLPy8Hz1VpfyyZXnxdtYCPOAb+Db1rOY0cvTS luF43QPJR4wX0LLoE9ajHokcrWFbNxn5LacEUiqoBq1bVyPAZJf5SaKb/GImOovnqKMT pn9SF8/57EfPGrBeuiXYacDXI+KK7ifUgH5nXAzNYI8F/Ge8JJpAK2k4DeasBwi/Mj/p 10qy4siUb3y2F9Wglt4I/LZkb7a9J1zEwB/DtFdf04KmTjA7dZ4wy7sXzJl8+AxlQv/H gUhg== X-Forwarded-Encrypted: i=1; AJvYcCUP89GU0LeAURaykmGWYKqXdItPZmoUJNX87WqnsDw1hBMY/NSQ/Kx5u4gGdSvQiFwq613DisE=@lists.linux.dev X-Gm-Message-State: AOJu0YzxV1jG0HYZuOdDmQj8BMukcZ/xPpGHDjCm4oVpBPAm7M36LLe2 cvKO5w5a7cwETJE2iXu0wBylgH+WuqoY7MkNu8CAzo63UcEXTjcsfRgwdn7mCbk3i7tUhZynmlh 4GctJVg== X-Google-Smtp-Source: AGHT+IGHOQLpfyFznvDWNUH7H5RRwumwXl+ad4M1fU9LKzyWdjNf4lBkOJxqkb3vWAdXWhUIZ0D4LKjuEDo= X-Received: from pjd14.prod.google.com ([2002:a17:90b:54ce:b0:339:ee20:f620]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3e4d:b0:32e:528c:60ee with SMTP id 98e67ed59e1d1-34083055b02mr1449393a91.24.1761855065570; Thu, 30 Oct 2025 13:11:05 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 30 Oct 2025 13:09:50 -0700 In-Reply-To: <20251030200951.3402865-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251030200951.3402865-1-seanjc@google.com> X-Mailer: git-send-email 2.51.1.930.gacf6e81ea2-goog Message-ID: <20251030200951.3402865-28-seanjc@google.com> Subject: [PATCH v4 27/28] KVM: TDX: Bug the VM if extending the initial measurement fails From: Sean Christopherson To: Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Sean Christopherson , Paolo Bonzini , "Kirill A. Shutemov" Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Ira Weiny , Kai Huang , Binbin Wu , Michael Roth , Yan Zhao , Vishal Annapurve , Rick Edgecombe , Ackerley Tng Content-Type: text/plain; charset="UTF-8" WARN and terminate the VM if TDH_MR_EXTEND fails, as extending the measurement should fail if and only if there is a KVM bug, or if the S-EPT mapping is invalid. Now that KVM makes all state transitions mutually exclusive via tdx_vm_state_guard, it should be impossible for S-EPT mappings to be removed between kvm_tdp_mmu_map_private_pfn() and tdh_mr_extend(). Holding slots_lock prevents zaps due to memslot updates, filemap_invalidate_lock() prevents zaps due to guest_memfd PUNCH_HOLE, vcpu->mutex locks prevents updates from other vCPUs, kvm->lock prevents VM-scoped ioctls from creating havoc (e.g. by creating new vCPUs), and all usage of kvm_zap_gfn_range() is mutually exclusive with S-EPT entries that can be used for the initial image. For kvm_zap_gfn_range(), the call from sev.c is obviously mutually exclusive, TDX disallows KVM_X86_QUIRK_IGNORE_GUEST_PAT so the same goes for kvm_noncoherent_dma_assignment_start_or_stop(), and __kvm_set_or_clear_apicv_inhibit() is blocked by virtue of holding all VM and vCPU mutexes (and the APIC page has its own non-guest_memfd memslot and so can't be used for the initial image, which means that too is mutually exclusive irrespective of locking). Opportunistically return early if the region doesn't need to be measured in order to reduce line lengths and avoid wraps. Similarly, immediately and explicitly return if TDH_MR_EXTEND fails to make it clear that KVM needs to bail entirely if extending the measurement fails. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/tdx.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index 8bcdec049ac6..762f2896547f 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -3123,21 +3123,23 @@ static int tdx_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, put_page(src_page); - if (ret) + if (ret || !(arg->flags & KVM_TDX_MEASURE_MEMORY_REGION)) return ret; - if (arg->flags & KVM_TDX_MEASURE_MEMORY_REGION) { - for (i = 0; i < PAGE_SIZE; i += TDX_EXTENDMR_CHUNKSIZE) { - err = tdh_mr_extend(&kvm_tdx->td, gpa + i, &entry, - &level_state); - if (err) { - ret = -EIO; - break; - } - } + /* + * Note, MR.EXTEND can fail if the S-EPT mapping is somehow removed + * between mapping the pfn and now, but slots_lock prevents memslot + * updates, filemap_invalidate_lock() prevents guest_memfd updates, + * mmu_notifier events can't reach S-EPT entries, and KVM's internal + * zapping flows are mutually exclusive with S-EPT mappings. + */ + for (i = 0; i < PAGE_SIZE; i += TDX_EXTENDMR_CHUNKSIZE) { + err = tdh_mr_extend(&kvm_tdx->td, gpa + i, &entry, &level_state); + if (TDX_BUG_ON_2(err, TDH_MR_EXTEND, entry, level_state, kvm)) + return -EIO; } - return ret; + return 0; } static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *cmd) -- 2.51.1.930.gacf6e81ea2-goog