From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (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 2305D21D5A8 for ; Fri, 20 Dec 2024 17:31:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715899; cv=none; b=c7s7OjpxcvkONOYAQgQbMfrJnwnVui31pUbRJnM+PLrL3xR4SFtuoclkvrNiPQs1wU5gKu3rA9eUj4bx6RfdyouaVb2muu9fX8PzIt3PcW2nzCzKwCnSuAPQJw4k2ZxfOxpkSoB2KHcHlYnoqBYJqqO0QDNmasbzIN/H7RooHLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715899; c=relaxed/simple; bh=y1oGFx+eDg9kZ5IMuBoG3ZGG20dZOVndvEoDVt31Ycs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=SSH6k9WACujmj4tBQIjzHkAmhlHpkUF8lyg/4p7HkRgz/G9Zqy4gJYSXakeKDDc9rO5bMn+kE0JjlCAN+Wrp+b8+2FSLz/cHPjW4Q9G/1bV0zCrl3KRcNLIpPQos9lQmB4G0RvSRP4O52/rBnaFmxaRJFcBq4ALCYwWlSjV3bq4= 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=IBBbVcRi; arc=none smtp.client-ip=209.85.210.202 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="IBBbVcRi" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-725eff499c0so1783743b3a.2 for ; Fri, 20 Dec 2024 09:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734715897; x=1735320697; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=nsV0/Gxa57HKjHyGRzj7RAv/zM0LUbJ0KCm4V/ZCMo0=; b=IBBbVcRige3t7Wqxkw8Nvvi6FozlFE2OH+Zx5jZMzuiY0oPeaV4iXPcz52+dMG8ON6 Eh/DAieXdyDJNVDr6TGjxZJFdzj65q5NnNSNyflD9Bg9nTgNYcmIA6DQUwM3Kl5ZAjAI YxdBMvaGVMCIHbNOQthy/CGcVGzTssy+sbwedS74J1nur7veQfZB6b8IOrAixXdgAGTc SvsbbNB+FbmVu+gfrWS9H12HWKEsz2Q/KHmE7v1bKjz4t4hazVl9GxGbtEIblArgmFBm 1qkcTh+1kNuiLENW8Fe/afXVg+gnps+i9AQ89kh8E/aZe3sj1kKKlPrjUSG0CYyayhzj rrew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734715897; x=1735320697; h=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=nsV0/Gxa57HKjHyGRzj7RAv/zM0LUbJ0KCm4V/ZCMo0=; b=Jm3ZIfxSnFMM9a0O6nYmqaDYt3/up/KGnc9s6oatrNqX8xfs/u+dUAJ1t6TFpWCd8y 2jgXdFtSHXO2u7x6XQ1WRKsZECrfhcZLBpJp0aQPBAZRIMFyBSqc0ELu0MMn/r/CJEwT eYDyys0IloAvbgvcuI7Rezgqx9MNtv+uY5rdd6BSSCpB0T+IKMYj3ExcQZVCKU16J24k M+suuGwNzt2VymliMgrUcypljdEIrfqA56Xp5sK+8zhsYu90g/taunWLqK+RJnTG2pom 2G9e42K1FYvP3YHMS+UUEyfiCgmMtlTSVEYUrcihxOo/3wfBWa5pQIuXtlFPO15iDoDN 315g== X-Forwarded-Encrypted: i=1; AJvYcCXdxMqVDd+QV5AvqxdD1Tpp5G9KugAS+kx8HZIHU4p6OUFqSbx+iNrNo20ouwd1jCFzGoB7Cm5J7REhdMQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzpwUIfN4+SrChh4bjkGYX64JTVL29g8b7X1D9jJrjhewe5N0Sv FVLjnMlel7y7dGVoorPMRW792gNZPTl02cHT6C7QH6gS5IkVQ3yQYdoHXdE6ktF0jV5RWL6U77b WkA== X-Google-Smtp-Source: AGHT+IEPj9ZIjaZC9FgIMIVaYOT4GEhUiRW0UzntN5wbVictxCKTNbFQ0wYzzRNqGoIuarstOSw6sINe6yM= X-Received: from pfbbt17.prod.google.com ([2002:a05:6a00:4391:b0:725:8ee5:e458]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7fa2:b0:1e0:d1c3:97d1 with SMTP id adf61e73a8af0-1e5e080294cmr6803966637.29.1734715897443; Fri, 20 Dec 2024 09:31:37 -0800 (PST) Date: Fri, 20 Dec 2024 09:31:35 -0800 In-Reply-To: <20241220082231.15884-1-yan.y.zhao@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20241220082027.15851-1-yan.y.zhao@intel.com> <20241220082231.15884-1-yan.y.zhao@intel.com> Message-ID: Subject: Re: [PATCH 1/2] KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking From: Sean Christopherson To: Yan Zhao Cc: pbonzini@redhat.com, peterx@redhat.com, rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Fri, Dec 20, 2024, Yan Zhao wrote: > Do not allow resetting dirty GFNs belonging to a memslot that does not > enable dirty tracking. > > vCPUs' dirty rings are shared between userspace and KVM. After KVM sets > dirtied entries in the dirty rings, userspace is responsible for > harvesting/resetting the dirtied entries and calling the ioctl > KVM_RESET_DIRTY_RINGS to inform KVM to advance the reset_index in the > dirty rings and invoke kvm_arch_mmu_enable_log_dirty_pt_masked() to clear > the SPTEs' dirty bits or perform write protection of GFNs. > > Although KVM does not set dirty entries for GFNs in a memslot that does not > enable dirty tracking, it is still possible for userspace to specify that > it has harvested a GFN belonging to such a memslot. When this happens, KVM > will be asked to clear dirty bits or perform write protection for GFNs in a > memslot that does not enable dirty tracking, which is not desired. > > For TDX, this unexpected resetting of dirty GFNs could cause inconsistency > between the mirror SPTE and the external SPTE in hardware (e.g., the mirror > SPTE has no write bit while it is writable in the external SPTE in > hardware). When kvm_dirty_log_manual_protect_and_init_set() is true and > when huge pages are enabled in TDX, this could even lead to > kvm_mmu_slot_gfn_write_protect() being called and the external SPTE being > removed. > > Signed-off-by: Yan Zhao > --- > virt/kvm/dirty_ring.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c > index d14ffc7513ee..1ce5352ea596 100644 > --- a/virt/kvm/dirty_ring.c > +++ b/virt/kvm/dirty_ring.c > @@ -66,7 +66,8 @@ static void kvm_reset_dirty_gfn(struct kvm *kvm, u32 slot, u64 offset, u64 mask) > > memslot = id_to_memslot(__kvm_memslots(kvm, as_id), id); > > - if (!memslot || (offset + __fls(mask)) >= memslot->npages) > + if (!memslot || (offset + __fls(mask)) >= memslot->npages || > + !kvm_slot_dirty_track_enabled(memslot)) Can you add a comment explaining that it's possible to try to update a memslot that isn't being dirty-logged if userspace is misbehaving? And specifically that userspace can write arbitrary data into the ring.