linux-kernel - Re: [PATCH v8 13/14] x86/kasan: Logical bit shift for kasan_mem_to

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: <CA+fCnZd4rJvKzdMPmpYmNSto_dbJ_v6fdNYv-13_vC2+bu-4bg@mail.gmail.com>
Date: Thu, 15 Jan 2026 04:57:15 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
Cc: Maciej Wieczor-Retman <m.wieczorretman@...me>, Andrey Ryabinin <ryabinin.a.a@...il.com>, 
	Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, 
	Vincenzo Frascino <vincenzo.frascino@....com>, Thomas Gleixner <tglx@...nel.org>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, kasan-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v8 13/14] x86/kasan: Logical bit shift for kasan_mem_to_shadow

On Wed, Jan 14, 2026 at 5:52 PM Maciej Wieczor-Retman
<maciej.wieczor-retman@...el.com> wrote:
>
> I'm a fan of trying to keep as much arch code in the arch directories.
>
> How about before putting a call here instead like:
>
>         if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
>                 if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0ULL)) ||
>                     addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
>                         return;
>         }
>
>         arch_kasan_non_canonical_hook()
> There would be the generic non-arch part above (and anything shared that might
> make sense here in the future) and all the arch related code would be hidden in
> the per-arch helper.
>
> So then we could move the part below:
>         if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) && IS_ENABLED(CONFIG_ARM64)) {
>                 if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0xFFULL << 56)) ||
>                     addr > (unsigned long)kasan_mem_to_shadow((void *)(~0ULL)))
>                         return;
>         }
> to /arch/arm64.
>
> For x86 we'd need to duplicate the generic part into
> arch_kasan_non_canonical_hook() call in /arch/x86. That seems quiet tidy to me,
> granted the duplication isn't great but it would keep the non-arch part as
> shared as possible. What do you think?

Sounds good to me too, thanks!