[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAeHK+x+DMs9jdeB58XaoJTO-kv+iiWT1_BuhYiJzJH-DoY9EQ@mail.gmail.com>
Date: Thu, 27 Aug 2020 14:22:55 +0200
From: Andrey Konovalov <andreyknvl@...gle.com>
To: Vincenzo Frascino <vincenzo.frascino@....com>,
Catalin Marinas <catalin.marinas@....com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Marco Elver <elver@...gle.com>,
Evgenii Stepanov <eugenis@...gle.com>,
Elena Petrova <lenaptr@...gle.com>,
Branislav Rankov <Branislav.Rankov@....com>,
Kevin Brodsky <kevin.brodsky@....com>,
Will Deacon <will.deacon@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 25/35] kasan: introduce CONFIG_KASAN_HW_TAGS
On Thu, Aug 27, 2020 at 1:31 PM Vincenzo Frascino
<vincenzo.frascino@....com> wrote:
>
> Hi Andrey,
>
> On 8/14/20 6:27 PM, Andrey Konovalov wrote:
> > +config·KASAN_HW_TAGS
> > +» bool·"Hardware·tag-based·mode"
> > +» depends·on·HAVE_ARCH_KASAN_HW_TAGS
> > +» depends·on·SLUB
> > +» help
> > +» ··Enables·hardware·tag-based·KASAN·mode.
> > +
> > +» ··This·mode·requires·both·Memory·Tagging·Extension·and·Top·Byte·Ignore
> > +» ··support·by·the·CPU·and·therefore·is·only·supported·for·modern·arm64
> > +» ··CPUs·(MTE·added·in·ARMv8.5·ISA).
> > +
>
> I do not thing we should make KASAN_HW_TAGS MTE specific especially because it
> is in the common code (e.g. SPARC ADI might want to implement it in future).
>
> Probably would be better to provide some indirection in the generic code an
> implement the MTE backend entirely in arch code.
>
> Thoughts?
I think we can reword the help text to say that it enables tag-based
KASAN mode that is backed by the hardware in general, and mention that
this is currently only implemented for arm64 through MTE. I don't
think it makes sense to provide a common arch interface at this point
to keep the code simpler. We can do that when (and if) another
hardware backend is added.
Powered by blists - more mailing lists