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 5B360288C2C for ; Fri, 20 Feb 2026 16:54:47 +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=1771606488; cv=none; b=CVVwLB8G5GAdpL2l47PCMiYwcfgj9AmFPWWtt4z7owNK3W3JqTJ484Qqhtn1TOQ4TnMBq0nz/obCLx3YtTsYEQaygNfoZXtJroUeN2a/r6G0Uc0/3wMB1vha4EHHuvPHH6j4T18btMNU32aEKRMEQmWvmifPwY+lePnQFoE7u6E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771606488; c=relaxed/simple; bh=uKJtCZaXbgW720WEGZpi9vqDGlLxa3Io2BYibYXb3AY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=riG9PNZsdn5AbhbywmT62HOZThL/GcYYDowhlghRO+qfXBpBvOF6uyCennSKsLHSIWQWAzM6Vvuynkq1LyljY6rcIa+At7Bu7mrU5lGV6d9C/aPB0DA+9Yt3GT8/yPblniJ9+/KvHwuqwx4t+Z4SQ+7+fpRnIYkTksVZ5zz6eqQ= 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=UKFaJAEW; 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="UKFaJAEW" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-3562171b56dso2399364a91.2 for ; Fri, 20 Feb 2026 08:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771606486; x=1772211286; 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=UGr7fqBn14oKU92GIyxBvn3jVsvgzYWTcMXy3dWUq0I=; b=UKFaJAEWl7765jNwSnveMYAiJDQKVOayIaMWhbgkbJIhfK2AUMP1YhJskim/l9NdwW rYSxAB1wYXvkWUsKZTAlSoDjv2vI1rpfmLyP2waM1vs9TV2aGQm+85UD+a9hut1L6Zpm 6b4sgMKQZPeKE5BLty3wLYQb43SN8r1LnEL1A2MdEWcJbU1oyRmO732dYPaBlYAKDre+ YuDtbkzber8Szt8HBYroBgLjctiRV6uWcIjyUDN2T9RTaxU+91pexZiARaBB3h/ygoUW vvNUP93E/APGCar9B6HxyrBQCSRaM2iOhU5+kEEGGZUKVSsqowLHW6da9ABMIrQTiv0q +h/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771606486; x=1772211286; 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=UGr7fqBn14oKU92GIyxBvn3jVsvgzYWTcMXy3dWUq0I=; b=qJ+S036GSX/GQNnomagBu14dSgjr1ZVq4UX0ewX7SrRhaM6bj6FMN2jabsi5WDm2uV 7FZ34PFstVk1u0W1Ez3ceAO3nJjr3AP/q3keHMU4ZsQud6ehqZHl6rbrTavcP//IU31d 43FkmBADN15AVNA8ac7vVOwDHmpWM9HrPeTcWo4IolLrNinbd43Iwn0LvsRK1VEq+V8A bod+jSeDnsEfjFqefVplKtahPkaZr8xg7PyhzQxO/NDyHv7CYsl9zwKBqmQUgOqazJiQ a5nKFipQEx8UZZR6Ynb3+jcFZFox+781yhjVxqjisMRMDI1NVjMp9FrlcCYWZfdwcnz9 ALtQ== X-Forwarded-Encrypted: i=1; AJvYcCUD3r3ixAJE+oe1VhMzcYS2zgPmOo2poZVSUklufwxy654KS3jPS65gdpUYrf0cgMLp4hTDkZUYfv1eqbc=@vger.kernel.org X-Gm-Message-State: AOJu0YxLeMCbAvVLR6jCoCFyUewb+Q/oqCkKj5kyPo5+EWJsm3tDX2t4 HL2fUsGHH5JRvTJ5OxJt26k7UVaJrYfDesiIQESZgKx+f8OD8lwM+eduVxKojLwl6sWYF27PxtS yuI2Cyg== X-Received: from pjvj5.prod.google.com ([2002:a17:90a:dc85:b0:34c:88ca:9ef8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5747:b0:34a:a1c1:90a0 with SMTP id 98e67ed59e1d1-358ae8c166dmr272204a91.28.1771606486410; Fri, 20 Feb 2026 08:54:46 -0800 (PST) Date: Fri, 20 Feb 2026 16:54:45 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260219002241.2908563-1-seanjc@google.com> Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Don't create SPTEs for addresses that aren't mappable From: Sean Christopherson To: "Edgecombe, Rick P" Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" +lists, because I'm confident there's no host attack. On Thu, Feb 19, 2026, Edgecombe, Rick P wrote: > On Wed, 2026-02-18 at 16:22 -0800, Sean Christopherson wrote: > > In practice, the flaw is benign (other than the new WARN) as it only > > affects guests that ignore guest.MAXPHYADDR (e.g. on CPUs with 52-bit > > physical addresses but only 4-level paging) or guests being run by a > > misbehaving userspace VMM (e.g. a VMM that ignored allow_smaller_maxphyaddr > > or is pre-faulting bad addresses). > > I tried to look at whether this is true from a hurt-the-host perspective. > > Did you consider the potential mismatch between the GFN passed to > kvm_flush_remote_tlbs_range() and the PTE's for different GFNs that actually got > touched. For example in recover_huge_pages_range(), if it flushed the wrong > range then the page table that got freed could still be in the intermediate > translation caches? I hadn't thought about this before you mentioned it, but I audited all code paths and all paths that lead to kvm_flush_remote_tlbs_range() use a "sanitized" gfn, i.e. KVM never emits a flush for the gfn reported by the fault. Which meshes with a logical analysis as well: KVM only needs to flush when removing/changing an entry, and so should always derive the to-be-flushed ranges using the gfn that was used to make the change. And the "bad" gfn can never have TLB entries, because KVM never creates mappings. FWIW, even if KVM screwed up something like recover_huge_pages_range(), it wouldn't hurt the _host_. Because from a host safety perspective, KVM x86 only needs to get it right in three paths: kvm_flush_shadow_all(), __kvm_gmem_invalidate_begin(), and kvm_mmu_notifier_invalidate_range_start(). > I'm not sure how this HV flush stuff actually works in practice, especially on > those details. So not raising any red flags. Just thought maybe worth > considering.