linux-kernel - Re: [PATCH v5 10/19] x86: LAM compatible non-canonical definition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <lcjxrakk556uveux3jxfkvikw2av2gwod22hxrt73zonh4663t@qn5u7xwbcr2f>
Date: Wed, 27 Aug 2025 08:32:15 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Samuel Holland <samuel.holland@...ive.com>
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>, <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>,
	<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>,
	<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>
Subject: Re: [PATCH v5 10/19] x86: LAM compatible non-canonical definition

On 2025-08-25 at 15:59:46 -0500, Samuel Holland wrote:
>Hi Maciej,
>
>On 2025-08-25 3:24 PM, Maciej Wieczor-Retman wrote:
>> 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
>
>These two implementations have different semantics. The new function works only
>on kernel addresses, whereas the existing one works on user addresses as well.
>It looks like at least KVM's use of __is_canonical_address() expects the
>function to work with user addresses.

Thanks for noticing that, I'll think of a way to make it work for user addresses
too :)

>
>Regards,
>Samuel
>
>>  
>>  static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits)
>>  {
>

-- 
Kind regards
Maciej Wieczór-Retman