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: <75a2eb31-3636-44d4-b2c9-3a24646499a4@gmail.com>
Date: Fri, 5 Sep 2025 19:12:01 +0200
From: Andrey Ryabinin <ryabinin.a.a@...il.com>
To: Andrey Konovalov <andreyknvl@...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 9/4/25 4:58 PM, Andrey Konovalov wrote:
> On Thu, Sep 4, 2025 at 10:11 AM Baoquan He <bhe@...hat.com> wrote:
>>
>>> If so, would it help if we make the kasan.vmalloc command-line
>>> parameter work with the non-HW_TAGS modes (and make it do the same
>>> thing as disabling CONFIG_KASAN_VMALLOC)?
>>>
>>> What I don't like about introducing kasan=off for non-HW_TAGS modes is
>>> that this parameter does not actually disable KASAN. It just
>>> suppresses KASAN code for mapping proper shadow memory. But the
>>> compiler-added instrumentation is still executing (and I suspect this
>>> might break the inline instrumentation mode).
>>
>> I may not follow your saying it doesn't disable KASAN. In this patchset,
>> not only do I disable the code for mapping shadow memory, but also I
>> skip any KASAN checking. Please see change of check_region_inline() in
>> mm/kasan/generic.c and kasan_check_range() in mm/kasan/sw_tags.c. It
>> will skip any KASAN checking when accessing memory.
>>
>> Yeah, the compiler added instrumentation will be called, but the if
>> (!kasan_enabled()) checking will decide if going further into KASAN code
>> or just return directly.
> 
> This all is true for the outline instrumentation mode.
> 
> However, with the inline instrumentation, check_region_inline() is not
> called (in many cases, at least) and instead the compiler embeds the
> instructions to calculate the shadow memory address and check its
> value directly (this is why we have CONFIG_KASAN_SHADOW_OFFSET, whose
> value has to be known at compile time).
> 
>> I tried inline mode on x86_64 and arm64, it
>> works well when one reviewer said inline mode could cost much more
>> memory, I don't see any breakage w or w/o kasan=off when this patchset
>> applied..
> 
> This is interesting. I guess what happens is that we still have the
> early shadow memory mapped so the shadow memory accesses inserted by
> the inline instrumentation do not crash.
> 
> 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.