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+fCnZcAa62uXqnUwxFmDYh1xPqKBOQqOT55kU8iY_pgQg2+NA@mail.gmail.com>
Date: Tue, 12 Aug 2025 18:57:37 +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 Tue, Aug 12, 2025 at 2:49 PM Baoquan He <bhe@...hat.com> wrote:
>
> Currently only hw_tags mode of kasan can be enabled or disabled with
> kernel parameter kasan=on|off for built kernel. For kasan generic and
> sw_tags mode, there's no way to disable them once kernel is built.
> This is not convenient sometime, e.g in system kdump is configured.
> When the 1st kernel has KASAN enabled and crash triggered to switch to
> kdump kernel, the generic or sw_tags mode will cost much extra memory
> for kasan shadow while in fact it's meaningless to have kasan in kdump
> kernel.
>
> So this patchset moves the kasan=on|off out of hw_tags scope and into
> common code to make it visible in generic and sw_tags mode too. Then we
> can add kasan=off in kdump kernel to reduce the unneeded meomry cost for
> kasan.

Hi Baoquan,

Could you clarify what are you trying to achieve by disabling
Generic/SW_TAGS KASAN via command-line? Do you want not to see any
KASAN reports produced? Or gain back the performance?

Because for the no reports goal, it would be much easier to add a
command-line parameter to silent the reports.

And the performance goal can only be partially achieved, as you cannot
remove the compiler instrumentation without rebuilding the kernel.
(What are the boot times for KASAN_GENERIC=n vs KASAN_GENERIC=y +
kasan=off vs KASAN_GENERIC=y btw?)

Thank you!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ