Message-ID: <pytojmt43uaunsqexyeo7anmjimzbqzec3nqla3hyzne7ttjvn@lwzrjoq3yx6w>
Date: Fri, 7 Feb 2025 08:41:35 +0100
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, "Christoph Lameter (Ampere)"
	<cl@...two.org>, <andreyknvl@...il.com>
CC: Jessica Clarke <jrtc27@...c27.com>, <luto@...nel.org>, <xin@...or.com>,
	<kirill.shutemov@...ux.intel.com>, <palmer@...belt.com>, <tj@...nel.org>,
	<brgerst@...il.com>, <ardb@...nel.org>, <dave.hansen@...ux.intel.com>,
	<jgross@...e.com>, <will@...nel.org>, <akpm@...ux-foundation.org>,
	<arnd@...db.de>, <corbet@....net>, <dvyukov@...gle.com>,
	<richard.weiyang@...il.com>, <ytcoode@...il.com>, <tglx@...utronix.de>,
	<hpa@...or.com>, <seanjc@...gle.com>, <paul.walmsley@...ive.com>,
	<aou@...s.berkeley.edu>, <justinstitt@...gle.com>, <jason.andryuk@....com>,
	<glider@...gle.com>, <ubizjak@...il.com>, <jannh@...gle.com>,
	<bhe@...hat.com>, <vincenzo.frascino@....com>, <rafael.j.wysocki@...el.com>,
	<ndesaulniers@...gle.com>, <mingo@...hat.com>, <catalin.marinas@....com>,
	<junichi.nomura@....com>, <nathan@...nel.org>, <ryabinin.a.a@...il.com>,
	<dennis@...nel.org>, <bp@...en8.de>, <kevinloughlin@...gle.com>,
	<morbo@...gle.com>, <dan.j.williams@...el.com>,
	<julian.stecklina@...erus-technology.de>, <peterz@...radead.org>,
	<kees@...nel.org>, <kasan-dev@...glegroups.com>, <x86@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-riscv@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>, <llvm@...ts.linux.dev>,
	<linux-doc@...r.kernel.org>, "Shutemov, Kirill" <kirill.shutemov@...el.com>
Subject: Re: [PATCH 00/15] kasan: x86: arm64: risc-v: KASAN tag-based mode
 for x86

On 2025-02-06 at 13:41:29 -0800, Dave Hansen wrote:
>On 2/6/25 11:11, Christoph Lameter (Ampere) wrote:
>> I also see that KASAN_HW_TAGS exist but this means that the tags can only
>> be used with CONFIG_KASAN which is a kernel configuration for debug
>> purposes.
>> 
>> What we are interested in is a *production* implementation with minimal
>> software overhead that will be the default on ARM64 if the appropriate
>> hardware is detected. 
>
>Ahh, interesting. I'd assumed that once folks had in-hardware tag checks
>that they'd just turn on CONFIG_KASAN and be happy.  Guess not!
>
>> That in turn will hopefully allow other software instrumentation
>> that is currently used to keep small objects secure and in turn
>> creates overhead.
>OK, so KASAN as-is is too broad. Are you saying that the kernel
>_currently_ have "software instrumentation" like SLAB
>redzoning/poisoning and you'd like to see MTE used to replace those?

I share Andrey's opinion that in hardware KASAN mode (with MTE on arm64) after
disabling stacktraces (which in my tests in software tag-based mode took up ~90%
of the allocation - small kmalloc() - time) and tweaking the bigger allocations
there doesn't seem to be anything more left in KASAN that'd be slowing things
down.

Obviously this series deals with the tag-based mode which will suffer from all
the software instrumentation penalties to performance. So while it's still a
debugging feature at least it gains 2x-4x memory savings over the generic mode
already present on x86.

>
>Are you just interested in small objects?  What counts as small?  I
>assume it's anything roughly <PAGE_SIZE.

Would disabling vmalloc instrumentation achieve something like this? That is
tweakable during compilation.

>
>_______________________________________________
>linux-riscv mailing list
>linux-riscv@...ts.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-riscv

-- 
Kind regards
Maciej Wieczór-Retman

Powered by blists - more mailing lists