[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200918093914.GC6335@gaia>
Date: Fri, 18 Sep 2020 10:39:14 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Vincenzo Frascino <vincenzo.frascino@....com>
Cc: Andrey Konovalov <andreyknvl@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>, 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-kernel@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 27/37] arm64: mte: Switch GCR_EL1 in kernel entry and
exit
On Thu, Sep 17, 2020 at 07:47:59PM +0100, Vincenzo Frascino wrote:
> On 9/17/20 5:52 PM, Catalin Marinas wrote:
> >> +void mte_init_tags(u64 max_tag)
> >> +{
> >> + u64 incl = GENMASK(max_tag & MTE_TAG_MAX, 0);
> >> +
> >> + gcr_kernel_excl = ~incl & SYS_GCR_EL1_EXCL_MASK;
> >> +}
> > Do we need to set the actual GCR_EL1 register here? We may not get an
> > exception by the time KASAN starts using it.
>
> It is ok not setting it here because to get exceptions cpuframework mte enable
> needs to be executed first. In that context we set even the register.
OK, that should do for now. If we ever add stack tagging, we'd have to
rethink the GCR_EL1 initialisation.
--
Catalin
Powered by blists - more mailing lists