linux-kernel - Re: [PATCH v2 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+fCnZfv9sbHuRVy8G9QdbKaaeO-Vguf7b2Atc5WXEs+uJx0YQ@mail.gmail.com>
Date: Thu, 14 Aug 2025 07:23:01 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Baoquan He <bhe@...hat.com>
Cc: linux-mm@...ck.org, ryabinin.a.a@...il.com, glider@...gle.com, 
	dvyukov@...gle.com, 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, 
	elver@...gle.com, snovitoll@...il.com
Subject: Re: [PATCH v2 00/12] mm/kasan: make kasan=on|off work for all three modes

On Wed, Aug 13, 2025 at 1:14 PM 'Baoquan He' via kasan-dev
<kasan-dev@...glegroups.com> wrote:
>
> > I'm not familiar with the internals of kdump, but would it be
> > possible/reasonable to teach kdump to ignore the KASAN shadow region?
>
> Yes, we can teach kdump to do that. Then people may hate those conditional
> check "if (is_kdump_kernel())" being added in kasan code. E.g even
> though we skip kasan_init(), we still need to check is_kdump_kernel()
> in kasan_populate_vmalloc(), right?
>
> Combined with the existing kasan_arch_is_ready(), it will make kasan code
> ugly. I planned to add kasan_enabled() via static key
> kasan_flag_enabled, then it can also easily remove kasan_arch_is_ready()
> cleanly.

What I had in mind was something different: into the kdump code, we
add a check whether the region of memory it's trying to dump is the
KASAN shadow, and make kdump not to dump this region.

Would this work? Would this help with the issue you have?

(I assume the problem is with the virtual region that is the shadow
memory, as kdump would dump all RAM either way? If not, please clarify
what how does the "heavy burden" that the shadow memory causes
manifests.)

Thank you!