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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ae927d3-0a66-4354-910f-155ff9ba3e0f@sifive.com>
Date: Mon, 25 Aug 2025 15:59:46 -0500
From: Samuel Holland <samuel.holland@...ive.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.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

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.

Regards,
Samuel

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