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: <29A74A26-E922-4A4F-9B4A-8DB0336B99DF@jrtc27.com>
Date: Thu, 6 Feb 2025 01:05:56 +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 5 Feb 2025, at 18:51, Christoph Lameter (Ampere) <cl@...two.org> wrote:
> 
> On Tue, 4 Feb 2025, Jessica Clarke wrote:
> 
>> 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
> 
> 
> On Ampere Processor hardware there is no penalty since the logic is build
> into the usual read/write paths. This is by design. There may be on other
> platforms that cannot do this.

You helpfully cut out all the explanation of where the performance
penalty comes from. But if it’s as you say I can only assume your
design chooses to stall all stores until they have actually written, in
which case you have a performance cost compared with hardware that
omitted MTE or optimises for non-synchronous MTE. The literature on MTE
agrees that it is not no penalty (but can be low penalty). I don’t
really want to have some big debate here about the ins and outs of MTE,
it’s not the place for it, but I will stand up and point out that
claiming MTE to be “no performance penalty” is misrepresentative of the
truth

Jess


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ