[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <239de2b9-0787-4105-a481-418dbd4d861e@intel.com>
Date: Thu, 6 Feb 2025 13:41:29 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>,
Jessica Clarke <jrtc27@...c27.com>
Cc: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, luto@...nel.org,
xin@...or.com, kirill.shutemov@...ux.intel.com, palmer@...belt.com,
tj@...nel.org, andreyknvl@...il.com, 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 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?
Are you just interested in small objects? What counts as small? I
assume it's anything roughly <PAGE_SIZE.
Powered by blists - more mailing lists