linux-kernel - Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes

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+fCnZf7jYPUyqHqonWhDKVi9eeN6aaaByMTBYCQrv2-8+hngQ@mail.gmail.com>
Date: Fri, 5 Sep 2025 22:34:26 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Andrey Ryabinin <ryabinin.a.a@...il.com>, Baoquan He <bhe@...hat.com>, snovitoll@...il.com
Cc: glider@...gle.com, dvyukov@...gle.com, elver@...gle.com, 
	linux-mm@...ck.org, vincenzo.frascino@....com, akpm@...ux-foundation.org, 
	kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org, 
	kexec@...ts.infradead.org, sj@...nel.org, lorenzo.stoakes@...cle.com, 
	christophe.leroy@...roup.eu
Subject: Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes

On Fri, Sep 5, 2025 at 7:12 PM Andrey Ryabinin <ryabinin.a.a@...il.com> wrote:
>
> > But have you tried running kasan=off + CONFIG_KASAN_STACK=y +
> > CONFIG_VMAP_STACK=y (+ CONFIG_KASAN_VMALLOC=y)? I would expect this
> > should causes crashes, as the early shadow is mapped as read-only and
> > the inline stack instrumentation will try writing into it (or do the
> > writes into the early shadow somehow get ignored?..).
>
> It's not read-only, otherwise we would crash very early before full shadow
> setup and won't be able to boot at all. So writes still happen, and shadow
> checked, but reports are disabled.
>
> So the patchset should work, but it's a little bit odd feature. With kasan=off we still
> pay x2-x3 performance penalty of compiler instrumentation and get nothing in return.
> So the usecase for this is if you don't want to compile and manage additional kernel binary
> (with CONFIG_KASAN=n) and don't care about performance at all.

Ack. So kasan=off would work but it's only benefit would be to avoid
the RAM overhead.

Baoquan, I'd be in favor of implementing kasan.vmalloc=off instead of
kasan=off. This seems to both (almost) solve the RAM overhead problem
you're having (AFAIU) and also seems like a useful feature on its own
(similar to CONFIG_KASAN_VMALLOC=n but via command-line). The patches
to support kasan.vmalloc=off should also be orthogonal to the
Sabyrzhan's series.

If you feel strongly that the ~1/8th RAM overhead (coming from the
physmap shadow and the slab redzones) is still unacceptable for your
use case (noting that the performance overhead (and the constant
silent detection of false-positive bugs) would still be there), I
think you can proceed with your series (unless someone else is
against).

I also now get what you meant that with your patches for the kasan=off
support, Sabyrzhan's CONFIG_ARCH_DEFER_KASAN would not be required
anymore: as every architecture would need a kasan_enabled() check,
every architecture would effectively need the CONFIG_ARCH_DEFER_KASAN
functionality (i.e. the static key to switch off KASAN).

Nevertheless, I still like the unification of the static keys usage
and the KASAN initialization calls that the Sabyrzhan's series
introduces, so I would propose to rebase your patches on top of his
(even though you would remove CONFIG_ARCH_DEFER_KASAN, but that seems
like a simple change) or pick out the related parts from his patches
(but this might not be the best approach in case someone discovers a
reason why kasan=off is a bad idea and we need to abandon the
kasan=off series).