Message-ID: <5dee53bb1044787199e143f7b5f6ec13204a3029.1755004923.git.maciej.wieczor-retman@intel.com>
Date: Tue, 12 Aug 2025 15:23:46 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: nathan@...nel.org,
	arnd@...db.de,
	broonie@...nel.org,
	Liam.Howlett@...cle.com,
	urezki@...il.com,
	will@...nel.org,
	kaleshsingh@...gle.com,
	rppt@...nel.org,
	leitao@...ian.org,
	coxu@...hat.com,
	surenb@...gle.com,
	akpm@...ux-foundation.org,
	luto@...nel.org,
	jpoimboe@...nel.org,
	changyuanl@...gle.com,
	hpa@...or.com,
	dvyukov@...gle.com,
	kas@...nel.org,
	corbet@....net,
	vincenzo.frascino@....com,
	smostafa@...gle.com,
	nick.desaulniers+lkml@...il.com,
	morbo@...gle.com,
	andreyknvl@...il.com,
	alexander.shishkin@...ux.intel.com,
	thiago.bauermann@...aro.org,
	catalin.marinas@....com,
	ryabinin.a.a@...il.com,
	jan.kiszka@...mens.com,
	jbohac@...e.cz,
	dan.j.williams@...el.com,
	joel.granados@...nel.org,
	baohua@...nel.org,
	kevin.brodsky@....com,
	nicolas.schier@...ux.dev,
	pcc@...gle.com,
	andriy.shevchenko@...ux.intel.com,
	wei.liu@...nel.org,
	bp@...en8.de,
	ada.coupriediaz@....com,
	xin@...or.com,
	pankaj.gupta@....com,
	vbabka@...e.cz,
	glider@...gle.com,
	jgross@...e.com,
	kees@...nel.org,
	jhubbard@...dia.com,
	joey.gouly@....com,
	ardb@...nel.org,
	thuth@...hat.com,
	pasha.tatashin@...een.com,
	kristina.martsenko@....com,
	bigeasy@...utronix.de,
	maciej.wieczor-retman@...el.com,
	lorenzo.stoakes@...cle.com,
	jason.andryuk@....com,
	david@...hat.com,
	graf@...zon.com,
	wangkefeng.wang@...wei.com,
	ziy@...dia.com,
	mark.rutland@....com,
	dave.hansen@...ux.intel.com,
	samuel.holland@...ive.com,
	kbingham@...nel.org,
	trintaeoitogc@...il.com,
	scott@...amperecomputing.com,
	justinstitt@...gle.com,
	kuan-ying.lee@...onical.com,
	maz@...nel.org,
	tglx@...utronix.de,
	samitolvanen@...gle.com,
	mhocko@...e.com,
	nunodasneves@...ux.microsoft.com,
	brgerst@...il.com,
	willy@...radead.org,
	ubizjak@...il.com,
	peterz@...radead.org,
	mingo@...hat.com,
	sohil.mehta@...el.com
Cc: linux-mm@...ck.org,
	linux-kbuild@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	x86@...nel.org,
	llvm@...ts.linux.dev,
	kasan-dev@...glegroups.com,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH v4 10/18] 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 15c95e96fd15..97de2878f0b3 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