From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 902313AFB08 for ; Tue, 26 May 2026 16:13:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779812004; cv=none; b=oudN+u9NH46rigc5WOOqZOParTM58P3W8IX8YEPwljTVplLzMFIadk0K49DXAk173Swz46znpXVJp/kacFHD71TB9nAUlX5OH7tl4QE/6ecoo/oBCqTdsKTeQwwZ4m8TB0daEvCEdaRqRkSpIURvxkXAYCFS26mo1lt8WROvWBY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779812004; c=relaxed/simple; bh=su9JZyL6kCCByom6RtyIOUZV/R46eYJ7VEk1jdF4Ucg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Zul/fUZcazKwSmzC7+dCYSSG/y+Ew/4VXPkSIPj/CrgA+9LLCvKH6+TsdbqB0aiEhDcydzYiRGAxQ2bDiPkisP90a28Z0dEj7ZmA7G2SttWlIuy6pUpVvh5lNeVqIO+hF96H3KvYzXbO4DSfDYEcDpGYCKahmgB0Ko1LNhC61w0= 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=FXd/xzLQ; arc=none smtp.client-ip=209.85.216.73 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="FXd/xzLQ" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-3663d5e9bf4so10908169a91.1 for ; Tue, 26 May 2026 09:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779812003; x=1780416803; 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=EKti3bpIeaw9DUQ7b6OosKHvIytGX0/8ZwQX1bJsL8w=; b=FXd/xzLQpHtKld142i7ZJa2VABUyIe6PW5JOIh3MQfiOWe29Be8eg8DrNYt5RW4wAb 55C2VfNq3OBs37cHt97m60w8ps6w/vxqq+LjiSYTrAH5zaSuzXCjud2xGAZbKwGcxQMr j2i92cZ73MUjq+c1o3l9x6DmQk1sJUv7Jnn74YHCc8ylY8kdMyK4HGPyZmyQrZSjv/Pk gR8G7Jv496X3L+hD0W9gRXPsRTl3COsx1MCQh2YYsR4YwOQZW7uu2ywwpMILynt81hYW uYh4vhDCa1eiVRjJO+oRyXcSDLswU8moiaytW0RihAIcwhqEG8mLpP/yzUJhsyAs9ika XQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779812003; x=1780416803; 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=EKti3bpIeaw9DUQ7b6OosKHvIytGX0/8ZwQX1bJsL8w=; b=UKFk2nlwh5ptKtjIdnJQiXaHjiYoUiew5EsoXmHAY+TmKzD8LjcYp8PLwa4ov6KK1e CDNjRQAfvfNL1I2V8JDRSoTdlHzbcWIavXZ6NYnt9SM2SEpAiz1aggnmV89yCPuGValp eEW0PjUp48hHFhqW1rFm9bwAk9Gl3R4YFTCaIjr/IUuXUkmbOkQaHty3aGwqKnPgWHc6 +vN+s2diuvn9dK2GAG1/cemjYQ04oUTTaCVJrItH2lfltrQfHRTZ6CWjMPB2ME2Whs3U XjVfjyoEb30DY54VnAaMZk7wIMKviCDU53vWranLCTy7Zumwji/tGEU1MkXF/ZzbpCbi e/qg== X-Forwarded-Encrypted: i=1; AFNElJ+LxSeQvojpTVUYuuWXfNjdg+kJAEmlaW1xdFXvUJy+lwFfDIvUTazOjPav0Y+n4gpE4HXmXCTjdPnDvc4=@vger.kernel.org X-Gm-Message-State: AOJu0YzFr0BEYF/qIO28spHCksEaXnr1u8vlDfJb79mIbtKVo9/GuEmO 1ywAh2prasa7IqbOjljq/xbJpJWmpq4Ic/rvPXT/PBsZ3blOC9FHkeskE8PbQXn+nYZYzgTl5Nm muAmREA== X-Received: from pjbsj15.prod.google.com ([2002:a17:90b:2d8f:b0:368:45e6:af08]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:33c1:b0:368:cefe:ddd0 with SMTP id 98e67ed59e1d1-36a6765aa6bmr17580098a91.15.1779812002650; Tue, 26 May 2026 09:13:22 -0700 (PDT) Date: Tue, 26 May 2026 09:13:21 -0700 In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-1-3f196bfad5a1@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260522-fix-sev-gmem-post-populate-v2-0-3f196bfad5a1@google.com> <20260522-fix-sev-gmem-post-populate-v2-1-3f196bfad5a1@google.com> Message-ID: Subject: Re: [PATCH v2 1/5] KVM: guest_memfd: Use write permissions when GUP-ing source pages From: Sean Christopherson To: Ackerley Tng Cc: Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Vishal Annapurve , Yan Zhao , Michael Roth , Isaku Yamahata , Chao Peng , Xiaoyao Li , Zongyao Chen , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Yu Zhang , Fuad Tabba Content-Type: text/plain; charset="us-ascii" The shortlog is misleading, bordering on outright wrong. I think most people would read it as "ALWAYS Use write permissions when GUP-ing source pages". I also think it should be scoped to: KVM: SEV: because this only affects SNP, and IMO is an SNP bug, not a guest_memfd bug. E.g. KVM: SEV: Pin source page for write when adding CPUID data for SNP guest On Fri, May 22, 2026, Ackerley Tng wrote: > From: Sean Christopherson > > sev_gmem_post_populate() may write to the source page if there was an error Avoid referencing function names in changelogs when possible. Unless the reader is already familiar with the code, the name is meaningless. The purpose of the changelog is to complement the literal patch, not to provide a play-by-play description. > while performing SNP_LAUNCH_UPDATE. > > Since GUP requested only reads, there is a chance sev_gmem_post_populate() > could be writing to some read-only page. > > sev_gmem_post_populate() will only ever write the source page if the type > of page being LAUNCH_UPDATEd is a CPUID page. Hence, request a writable > page only when loading the CPUID page. > > Since TDX never writes to the source page, always pass false to > kvm_gmem_populate(). Describe changes in human-friendly, conversational language. And in a way that doesn't require looking at the patch to understand the changelog: "pass false" is meaningless without looking at the code to see what flag was added (or exists). > With this, even if a read-only mapping or the global zero page was provided > as the source page, GUP will do a copy-on-write, making it writable before > the write happens in gvm_post_populate. Objection, speculation. If the mapping is truly read-only, i.e. doesn't allow writes at all, then GUP will fail. This is all superfluous information though; "read-only" is a pretty ubiquitous concept, there's no need to explain it in gory detail. I'll rewrite to this when applying: --- When populating a guest_memfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the "correct" CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory. Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping. --- > Fixes: 2a62345b30529 ("KVM: guest_memfd: GUP source pages prior to populating guest memory") > Signed-off-by: Sean Christopherson Cc: stable@vger.kernel.org > Signed-off-by: Ackerley Tng > ---