Message-ID: <c1902b7c161632681dac51bc04ab748853e616d0.1756151769.git.maciej.wieczor-retman@intel.com>
Date: Mon, 25 Aug 2025 22:24:35 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: sohil.mehta@...el.com,
	baohua@...nel.org,
	david@...hat.com,
	kbingham@...nel.org,
	weixugc@...gle.com,
	Liam.Howlett@...cle.com,
	alexandre.chartre@...cle.com,
	kas@...nel.org,
	mark.rutland@....com,
	trintaeoitogc@...il.com,
	axelrasmussen@...gle.com,
	yuanchu@...gle.com,
	joey.gouly@....com,
	samitolvanen@...gle.com,
	joel.granados@...nel.org,
	graf@...zon.com,
	vincenzo.frascino@....com,
	kees@...nel.org,
	ardb@...nel.org,
	thiago.bauermann@...aro.org,
	glider@...gle.com,
	thuth@...hat.com,
	kuan-ying.lee@...onical.com,
	pasha.tatashin@...een.com,
	nick.desaulniers+lkml@...il.com,
	vbabka@...e.cz,
	kaleshsingh@...gle.com,
	justinstitt@...gle.com,
	catalin.marinas@....com,
	alexander.shishkin@...ux.intel.com,
	samuel.holland@...ive.com,
	dave.hansen@...ux.intel.com,
	corbet@....net,
	xin@...or.com,
	dvyukov@...gle.com,
	tglx@...utronix.de,
	scott@...amperecomputing.com,
	jason.andryuk@....com,
	morbo@...gle.com,
	nathan@...nel.org,
	lorenzo.stoakes@...cle.com,
	mingo@...hat.com,
	brgerst@...il.com,
	kristina.martsenko@....com,
	bigeasy@...utronix.de,
	luto@...nel.org,
	jgross@...e.com,
	jpoimboe@...nel.org,
	urezki@...il.com,
	mhocko@...e.com,
	ada.coupriediaz@....com,
	hpa@...or.com,
	maciej.wieczor-retman@...el.com,
	leitao@...ian.org,
	peterz@...radead.org,
	wangkefeng.wang@...wei.com,
	surenb@...gle.com,
	ziy@...dia.com,
	smostafa@...gle.com,
	ryabinin.a.a@...il.com,
	ubizjak@...il.com,
	jbohac@...e.cz,
	broonie@...nel.org,
	akpm@...ux-foundation.org,
	guoweikang.kernel@...il.com,
	rppt@...nel.org,
	pcc@...gle.com,
	jan.kiszka@...mens.com,
	nicolas.schier@...ux.dev,
	will@...nel.org,
	andreyknvl@...il.com,
	jhubbard@...dia.com,
	bp@...en8.de
Cc: x86@...nel.org,
	linux-doc@...r.kernel.org,
	linux-mm@...ck.org,
	llvm@...ts.linux.dev,
	linux-kbuild@...r.kernel.org,
	kasan-dev@...glegroups.com,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: [PATCH v5 10/19] x86: LAM compatible non-canonical definition

For an address to be canonical it has to have its top bits equal to each
other. The number of bits depends on the paging level and whether
they're supposed to be ones or zeroes depends on whether the address
points to kernel or user space.

With Linear Address Masking (LAM) enabled, the definition of linear
address canonicality is modified. Not all of the previously required
bits need to be equal, only the first and last from the previously equal
bitmask. So for example a 5-level paging kernel address needs to have
bits [63] and [56] set.

Add separate __canonical_address() implementation for
CONFIG_KASAN_SW_TAGS since it's the only thing right now that enables
LAM for kernel addresses (LAM_SUP bit in CR4).

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
---
Changelog v4:
- Add patch to the series.

 arch/x86/include/asm/page.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index bcf5cad3da36..a83f23a71f35 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -82,10 +82,20 @@ static __always_inline void *pfn_to_kaddr(unsigned long pfn)
 	return __va(pfn << PAGE_SHIFT);
 }
 
+/*
+ * CONFIG_KASAN_SW_TAGS requires LAM which changes the canonicality checks.
+ */
+#ifdef CONFIG_KASAN_SW_TAGS
+static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits)
+{
+	return (vaddr | BIT_ULL(63) | BIT_ULL(vaddr_bits - 1));
+}
+#else
 static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits)
 {
 	return ((s64)vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits);
 }
+#endif
 
 static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits)
 {
-- 
2.50.1

Powered by blists - more mailing lists