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: <94f81328-a135-b99b-7f73-43fb77bd7292@gentwo.org>
Date: Thu, 6 Feb 2025 11:11:16 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: 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
Subject: Re: [PATCH 00/15] kasan: x86: arm64: risc-v: KASAN tag-based mode
 for x86

On Thu, 6 Feb 2025, Jessica Clarke wrote:

> On 5 Feb 2025, at 18:51, Christoph Lameter (Ampere) <cl@...two.org> wrote:
> > 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

I cannot share details since this information has not been released to be
public yet. I hear that a whitepaper will be coming soon to explain this
feature. The AmpereOne processors have been released a couple of months
ago.

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. That in turn will hopefully allow other software
instrumentation that is currently used to keep small objects secure and in
turn creates overhead.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ