From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E6BF72602 for ; Wed, 7 Jan 2026 23:17:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767827823; cv=none; b=ktK4WDatzsUG1tDsogu7JftziaHJwn4TACReXSSSnxT7tGB3aWjNY2wrHF3zkFdt1c41Uhb+VJp18TKsyowXqnCzD00TPjdHN1f+Zva9D2ARx0w2w/vbuQpBLpAB5OYw4LaJPddOdnLYRlIso90VnO/r0rtTI6ZKqgJLwbwo4fg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767827823; c=relaxed/simple; bh=IZuycxfoXVDjxK11CSySfGPl5GvrLjcBRTW92uTTXQU=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=lLyYOh3uHVs5TLwGeVUw+j0IWqtO3T4UnesJnScutmsfsL98+zvr3fIQJBOQaxtjUHqbobJ3WUapN0hCK0MJf0pDtlhL+0Kv96Pv30i+sLldyOL4thMCJq3IfIqPVlSMSl2D97UzUEksbdNJ8+bZop4vCRwV85XumosAcjb6Vqw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=kPXLC1Q8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="kPXLC1Q8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B315C4CEF1; Wed, 7 Jan 2026 23:17:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1767827821; bh=IZuycxfoXVDjxK11CSySfGPl5GvrLjcBRTW92uTTXQU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kPXLC1Q8Trh4l9q+StpRif+0qLzyGNs5nfiphSOSc63POuiN+W2A/Tt8e/RDa2fgJ w5/uq3d6/oLud5fGm2DdVB+++/lNBiy4vhRJTaZCmqfefUQ/da04zKKvvdWcFMdfoG Ef8IRobZVb14+XPAftYc0V6g364/8mQEqo7xVT84= Date: Wed, 7 Jan 2026 15:17:00 -0800 From: Andrew Morton To: Andrew Cooper Cc: LKML , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Jann Horn , kasan-dev@googlegroups.com Subject: Re: [PATCH] x86/kfence: Avoid writing L1TF-vulnerable PTEs Message-Id: <20260107151700.c7b9051929548391e92cfb3e@linux-foundation.org> In-Reply-To: <20260106180426.710013-1-andrew.cooper3@citrix.com> References: <20260106180426.710013-1-andrew.cooper3@citrix.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 6 Jan 2026 18:04:26 +0000 Andrew Cooper wrote: > For native, the choice of PTE is fine. There's real memory backing the > non-present PTE. However, for XenPV, Xen complains: > > (XEN) d1 L1TF-vulnerable L1e 8010000018200066 - Shadowing > > To explain, some background on XenPV pagetables: > > Xen PV guests are control their own pagetables; they choose the new PTE > value, and use hypercalls to make changes so Xen can audit for safety. > > In addition to a regular reference count, Xen also maintains a type > reference count. e.g. SegDesc (referenced by vGDT/vLDT), > Writable (referenced with _PAGE_RW) or L{1..4} (referenced by vCR3 or a > lower pagetable level). This is in order to prevent e.g. a page being > inserted into the pagetables for which the guest has a writable mapping. > > For non-present mappings, all other bits become software accessible, and > typically contain metadata rather a real frame address. There is nothing > that a reference count could sensibly be tied to. As such, even if Xen > could recognise the address as currently safe, nothing would prevent that > frame from changing owner to another VM in the future. > > When Xen detects a PV guest writing a L1TF-PTE, it responds by activating > shadow paging. This is normally only used for the live phase of > migration, and comes with a reasonable overhead. > > KFENCE only cares about getting #PF to catch wild accesses; it doesn't care > about the value for non-present mappings. Use a fully inverted PTE, to > avoid hitting the slow path when running under Xen. > > While adjusting the logic, take the opportunity to skip all actions if the > PTE is already in the right state, half the number PVOps callouts, and skip > TLB maintenance on a !P -> P transition which benefits non-Xen cases too. > > Fixes: 1dc0da6e9ec0 ("x86, kfence: enable KFENCE for x86") Seems that I sent 1dc0da6e9ec0 upstream so thanks, I'll grab this. If an x86 person chooses to handle it then I'll drop the mm.git version. I'll add a cc:stable to the mm.git copy, just to be sure. > Tested-by: Marco Elver > Signed-off-by: Andrew Cooper > --- That "^---$" tells tooling "changelog stops here". > CC: Alexander Potapenko > CC: Marco Elver > CC: Dmitry Vyukov > CC: Thomas Gleixner > CC: Ingo Molnar > CC: Borislav Petkov > CC: Dave Hansen > CC: x86@kernel.org > CC: "H. Peter Anvin" > CC: Andrew Morton > CC: Jann Horn > CC: kasan-dev@googlegroups.com > CC: linux-kernel@vger.kernel.org > > v1: > * First public posting. This went to security@ first just in case, and > then I got districted with other things ahead of public posting. > --- That "^---$" would be better placed above the versioning info. > > ... >