Message-Id: <0BDD645A-3BBE-4A85-9098-257B281A3BA0@jrtc27.com>
Date: Tue, 4 Feb 2025 23:36:23 +0000
From: Jessica Clarke <jrtc27@...c27.com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
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
Subject: Re: [PATCH 00/15] kasan: x86: arm64: risc-v: KASAN tag-based mode for
 x86

On 4 Feb 2025, at 18:58, Christoph Lameter (Ampere) <cl@...two.org> wrote:
> ARM64 supports MTE which is hardware support for tagging 16 byte granules
> and verification of tags in pointers all in hardware and on some platforms
> with *no* performance penalty since the tag is stored in the ECC areas of
> DRAM and verified at the same time as the ECC.
> 
> Could we get support for that? This would allow us to enable tag checking
> in production systems without performance penalty and no memory overhead.

It’s not “no performance penalty”, there is a cost to tracking the MTE
tags for checking. In asynchronous (or asymmetric) mode that’s not too
bad, but in synchronous mode there is a significant overhead even with
ECC. Normally on a store, once you’ve translated it and have the data,
you can buffer it up and defer the actual write until some time later.
If you hit in the L1 cache then that will probably be quite soon, but
if you miss then you have to wait for the data to come back from lower
levels of the hierarchy, potentially all the way out to DRAM. Or if you
have a write-around cache then you just send it out to the next level
when it’s ready. But now, if you have synchronous MTE, you cannot
retire your store instruction until you know what the tag for the
location you’re storing to is; effectively you have to wait until you
can do the full cache lookup, and potentially miss, until it can
retire. This puts pressure on the various microarchitectural structures
that track instructions as they get executed, as instructions are now
in flight for longer. Yes, it may well be that it is quicker for the
memory controller to get the tags from ECC bits than via some other
means, but you’re already paying many many cycles at that point, with
the relevant store being stuck unable to retire (and thus every
instruction after it in the instruction stream) that whole time, and no
write allocate or write around schemes can help you, because you
fundamentally have to wait for the tags to be read before you know if
the instruction is going to trap.

Now, you can choose to not use synchronous mode due to that overhead,
but that’s nuance that isn’t considered by your reply here and has some
consequences.

Jess

Powered by blists - more mailing lists