From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.232 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792580828; b=Fn/uvoC2wBc/cSgQDDhVM34fG0DmLWSKuKFelcts6U1skMqvlUAIMX9qSATxSGxdniF4 AClvnIUoRr+g1wFfopJIuUUCq/ra8gtgs5hgCqgDjCIzHzpZVPhtHh+1AmqHKp14fBVMe kcdyfmofP/n+yH9KHIWmX/3bVbFHRicHQ1DOt/XKonkqlztWNc9RvW2mJdLPtEwKmhi4M HKdaFobEDDWldYq80GdsOZbb/RKt3bfA10ovoAWp9z3GzFPIg4WFbQ0p3Hwd3ZVZouakF F5jWTYzM5QMvl/G9Af/N0uTrNx6FDEaVCEn1PTuE9fkzcC1PN3STJp++NGijMa/Sqkg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792580828; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=/Lx6DShk9reJacpbaAFxTHNuqC347ivhuY9XrUZ9h1Q=; b=MyImWMRjkVZL5uIHihyeREYiDLMaWDxMngsAvO5bcysGZ+ASVHJSwtrpIZd8K3pyJ96K lM2rn8yXt78cB8CzBxLDgDP9G0ZQWIW6RBxAUUEySLUiD5O8Ek4M/o4hZSdnWFAxmcCbP WgczrfivBQtGVqTSpZ6f2H4Bam5Uxr02VyDIoj/nq2SrUwKqRwxTAZxgnJXf3PZQ3nV+K c5mHThK14qw/+ID65qUKSAiJa9RR9DAZ9ZOg4la2/rUMa16x6KHuawl6p83ExSiUlq6vl Rei+wvNy1k9phBDrwj2W31Az4MJSUdCRmbftmpfAVcI9k2BLZtOrD4GgVq/626iOTQA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=eWdl5Unh; arc=none smtp.remote-ip=91.218.175.232 Received: from mta0.migadu.com (out-232.mta0.migadu.com [91.218.175.232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA83F606A31B for ; Wed, 21 Oct 2026 11:07:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org EA83F606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=eWdl5Unh X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=S4bD+01K5/KhrqQzm+KUd+2uczOY+o8D7HdNxOh0FzY=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792580825; v=1; x=1793185625; b=eWdl5Unh0QbJSum1DTWrzU1OMHs8bda11JkV+h6l6Da8OvokmBxGo1PhZy5KN67+4V2/I4kY gNhAOMFoznERIl+V2tAzu0/supNaU3ILKAUx1Wz+Zuih7ZCLE1vtzbJGvEsORoi33IUlAE7fvij 4pxhHsCB0gsJvE5KAcf2PMCM= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id b5ddc05ed2452df9; Wed, 21 Oct 2026 11:07:04 +0000 X-Mizu-Trace-ID: b5ddc05ed2452df9 X-Migadu-Flow: FLOW_OUT From: Fuad Tabba To: Marc Zyngier , Oliver Upton , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Catalin Marinas , Will Deacon , Mark Rutland , Steven Price , Yang Shi , David Hildenbrand , Lorenzo Stoakes , Fuad Tabba , linux-kernel@vger.kernel.org Subject: [PATCH v2 0/4] KVM: arm64: Fix stale MTE tags reaching a guest Date: Wed, 21 Oct 2026 12:06:56 +0100 Message-ID: <20261021110700.493315-1-fuad.tabba@linux.dev> X-Mailer: git-send-email 2.47.3 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi folks, Changes since v1 [1]: - Added patch 4, mte_clear_folio_tags(). (Lorenzo) - Moved patch 3's sanitise_mte_tags() call into the kvm_pgtable_stage2_map() branch. (Lorenzo) - Patch 1 loops with folio_page() rather than reusing page, and its comment now matches patch 2's. (Lorenzo) - Collected Reviewed-by from Lorenzo on patches 1-3. (thanks!) Three fixes for hugetlb and THP pages that reach an MTE guest without their tags cleared, so the guest can read whatever tags the pages' previous owners left. The first clears the whole of a hugetlb folio before marking it tagged, rather than only the pages being mapped. The second does the same when KVM_ARM_MTE_COPY_TAGS copies tags into a page. The third sanitises when a permission fault installs a THP block, and runs the VM_MTE_ALLOWED check on permission faults too. A VMM that maps guest memory with PROT_MTE isn't affected, as faulting that memory into its mapping clears the tags first. QEMU and kvmtool map it without. The fourth is a cleanup: it factors out the first two patches' folio-clearing loop into mte_clear_folio_tags(), which mte_sync_tags() now uses too. I have a reproducer that reads the previous owner's tag from 511 of 512 pages in each case. With this series applied, it reads none. Based on Linux 7.3-rc3 (fd73f4a665989; also applies to kvmarm/next dd0bc00e3e920 with a three-way merge). Cheers, /fuad [1] https://lore.kernel.org/all/20261019132103.3836646-1-fuad.tabba@linux.dev/ Fuad Tabba (4): KVM: arm64: Clear the whole hugetlb folio when sanitising MTE tags KVM: arm64: Clear the whole hugetlb folio when storing MTE tags KVM: arm64: Sanitise MTE tags when a permission fault installs a mapping arm64: mte: Add mte_clear_folio_tags() arch/arm64/include/asm/mte.h | 4 ++++ arch/arm64/kernel/mte.c | 15 ++++++++++----- arch/arm64/kvm/guest.c | 11 +++++++---- arch/arm64/kvm/mmu.c | 13 ++++++------- 4 files changed, 27 insertions(+), 16 deletions(-) base-commit: fd73f4a6659897191fa0d40695fe370925dd3780 -- 2.47.3