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] [day] [month] [year] [list]
Message-ID: <CA+fCnZf0z526E31AN_NUM-ioaGm+YF2kn02NwGU6-fmki-tkCg@mail.gmail.com>
Date: Sat, 6 Sep 2025 15:25:15 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Baoquan He <bhe@...hat.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, Andrey Ryabinin <ryabinin.a.a@...il.com>, snovitoll@...il.com
Subject: Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes

On Fri, Sep 5, 2025 at 10:34 PM Andrey Konovalov <andreyknvl@...il.com> wrote:
>
> 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).

Hm, just realized that kasan.vmalloc=off would probably break if
CONFIG_VMAP_STACK is enabled: read-only shadow for vmalloc =>
read-only shadow for stacks => stack instrumentation will try writing
into read-only shadow and crash.

So I wonder if there's a way to avoid the lazy vmap freeing to deal
with the RAM overhead.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ