linux-kernel - Re: [PATCH 1/9] kasan: unify static kasan_flag

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: <CACzwLxj3KWdy-mBu-te1OFf2FZ8eTp5CieYswF5NVY4qPWD93Q@mail.gmail.com>
Date: Thu, 26 Jun 2025 14:31:05 +0500
From: Sabyrzhan Tasbolatov <snovitoll@...il.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: ryabinin.a.a@...il.com, glider@...gle.com, andreyknvl@...il.com, 
	dvyukov@...gle.com, vincenzo.frascino@....com, catalin.marinas@....com, 
	will@...nel.org, chenhuacai@...nel.org, kernel@...0n.name, 
	maddy@...ux.ibm.com, mpe@...erman.id.au, npiggin@...il.com, hca@...ux.ibm.com, 
	gor@...ux.ibm.com, agordeev@...ux.ibm.com, borntraeger@...ux.ibm.com, 
	svens@...ux.ibm.com, richard@....at, anton.ivanov@...bridgegreys.com, 
	johannes@...solutions.net, dave.hansen@...ux.intel.com, luto@...nel.org, 
	peterz@...radead.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	x86@...nel.org, hpa@...or.com, chris@...kel.net, jcmvbkbc@...il.com, 
	akpm@...ux-foundation.org, guoweikang.kernel@...il.com, geert@...ux-m68k.org, 
	rppt@...nel.org, tiwei.btw@...group.com, richard.weiyang@...il.com, 
	benjamin.berg@...el.com, kevin.brodsky@....com, kasan-dev@...glegroups.com, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	loongarch@...ts.linux.dev, linuxppc-dev@...ts.ozlabs.org, 
	linux-s390@...r.kernel.org, linux-um@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH 1/9] kasan: unify static kasan_flag_enabled across modes

On Wed, Jun 25, 2025 at 3:35 PM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
>
>
>
> Le 25/06/2025 à 11:52, Sabyrzhan Tasbolatov a écrit :
> > Historically the fast-path static key `kasan_flag_enabled` existed
> > only for `CONFIG_KASAN_HW_TAGS`. Generic and SW_TAGS either relied on
> > `kasan_arch_is_ready()` or evaluated KASAN checks unconditionally.
> > As a result every architecture had to toggle a private flag
> > in its `kasan_init()`.
> >
> > This patch turns the flag into a single global runtime predicate that
> > is built for every `CONFIG_KASAN` mode and adds a helper that flips
> > the key once KASAN is ready.
>
> Shouldn't kasan_init_generic() also perform the following line to reduce
> even more code duplication between architectures ?
>
>         init_task.kasan_depth = 0;

I've tried to introduce a new function kasan_mark_ready() to gather
all arch duplicated code in one place:

In mm/kasan/common.c:

void __init kasan_mark_ready(void)
{
        /* Enable error reporting */
        init_task.kasan_depth = 0;
        /* Mark KASAN as ready */
        static_branch_enable(&kasan_flag_enabled);
}

So we could've called it
in mm/kasan/generic.c:
void __init kasan_init_generic(void)
{
        kasan_mark_ready();
        pr_info("KernelAddressSanitizer initialized (generic)\n");
}

in mm/kasan/sw_tags.c:
void __init kasan_init_sw_tags(void)
{
...
        kasan_mark_ready();
        pr_info("KernelAddressSanitizer initialized ..");
}

in mm/kasan/hw_tags.c:
void __init kasan_init_hw_tags(void)
{
...
        kasan_mark_ready();
        pr_info("KernelAddressSanitizer initialized ..");
}

But it works only for CONFIG_KASAN_GENERIC mode,
when arch code calls kasan_init(), for example, arm64:

void __init kasan_init(void)
{
        kasan_init_shadow();
        kasan_init_generic();
}

And for HW_TAGS, SW_TAGS it won't work.
Fails during compiling:
mm/kasan/common.c:45:12: error: no member named 'kasan_depth' in
'struct task_struct'
   45 |         init_task.kasan_depth = 0;

because kasan_init_sw_tags(), kasan_init_hw_tags() are called
once on CPU boot. For arm64, where these KASAN modes are supported,
both functions are called in smp_prepare_boot_cpu().

So I guess, every arch kasan_init() has to set in kasan_init()
       init_task.kasan_depth = 0;
to enable error messages before switching KASAN readiness
via enabling kasan_flag_enabled key.

>
> Christophe
>