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: <CANpmjNM+ot5A-pRLhV6Esn=QvCeCStd9fG_pgwrVA=6pxD8aqw@mail.gmail.com>
Date: Mon, 10 Nov 2025 15:49:22 +0100
From: Marco Elver <elver@...gle.com>
To: Maciej Wieczor-Retman <m.wieczorretman@...me>
Cc: xin@...or.com, peterz@...radead.org, kaleshsingh@...gle.com, 
	kbingham@...nel.org, akpm@...ux-foundation.org, nathan@...nel.org, 
	ryabinin.a.a@...il.com, dave.hansen@...ux.intel.com, bp@...en8.de, 
	morbo@...gle.com, jeremy.linton@....com, smostafa@...gle.com, kees@...nel.org, 
	baohua@...nel.org, vbabka@...e.cz, justinstitt@...gle.com, 
	wangkefeng.wang@...wei.com, leitao@...ian.org, jan.kiszka@...mens.com, 
	fujita.tomonori@...il.com, hpa@...or.com, urezki@...il.com, ubizjak@...il.com, 
	ada.coupriediaz@....com, nick.desaulniers+lkml@...il.com, ojeda@...nel.org, 
	brgerst@...il.com, pankaj.gupta@....com, glider@...gle.com, 
	mark.rutland@....com, trintaeoitogc@...il.com, jpoimboe@...nel.org, 
	thuth@...hat.com, pasha.tatashin@...een.com, dvyukov@...gle.com, 
	jhubbard@...dia.com, catalin.marinas@....com, yeoreum.yun@....com, 
	mhocko@...e.com, lorenzo.stoakes@...cle.com, samuel.holland@...ive.com, 
	vincenzo.frascino@....com, bigeasy@...utronix.de, surenb@...gle.com, 
	ardb@...nel.org, Liam.Howlett@...cle.com, nicolas.schier@...ux.dev, 
	ziy@...dia.com, kas@...nel.org, tglx@...utronix.de, mingo@...hat.com, 
	broonie@...nel.org, corbet@....net, andreyknvl@...il.com, 
	maciej.wieczor-retman@...el.com, david@...hat.com, maz@...nel.org, 
	rppt@...nel.org, will@...nel.org, luto@...nel.org, kasan-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	x86@...nel.org, linux-kbuild@...r.kernel.org, linux-mm@...ck.org, 
	llvm@...ts.linux.dev, linux-doc@...r.kernel.org
Subject: Re: [PATCH v6 17/18] x86/kasan: Logical bit shift for kasan_mem_to_shadow

On Wed, 29 Oct 2025 at 21:11, Maciej Wieczor-Retman
<m.wieczorretman@...me> wrote:
>
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>
> While generally tag-based KASAN adopts an arithemitc bit shift to
> convert a memory address to a shadow memory address, it doesn't work for
> all cases on x86. Testing different shadow memory offsets proved that
> either 4 or 5 level paging didn't work correctly or inline mode ran into
> issues. Thus the best working scheme is the logical bit shift and
> non-canonical shadow offset that x86 uses for generic KASAN, of course
> adjusted for the increased granularity from 8 to 16 bytes.
>
> Add an arch specific implementation of kasan_mem_to_shadow() that uses
> the logical bit shift.
>
> The non-canonical hook tries to calculate whether an address came from
> kasan_mem_to_shadow(). First it checks whether this address fits into
> the legal set of values possible to output from the mem to shadow
> function.
>
> Tie both generic and tag-based x86 KASAN modes to the address range
> check associated with generic KASAN.
>
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
> ---
> Changelog v4:
> - Add this patch to the series.
>
>  arch/x86/include/asm/kasan.h | 7 +++++++
>  mm/kasan/report.c            | 5 +++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
> index 375651d9b114..2372397bc3e5 100644
> --- a/arch/x86/include/asm/kasan.h
> +++ b/arch/x86/include/asm/kasan.h
> @@ -49,6 +49,13 @@
>  #include <linux/bits.h>
>
>  #ifdef CONFIG_KASAN_SW_TAGS
> +static inline void *__kasan_mem_to_shadow(const void *addr)
> +{
> +       return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
> +               + KASAN_SHADOW_OFFSET;
> +}

You're effectively undoing "kasan: sw_tags: Use arithmetic shift for
shadow computation" for x86 - why?
This function needs a comment explaining this.

Also, the commit message just says "it doesn't work for all cases" - why?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ