Message-ID: <CAMn1gO4t1hGSTKE0fLCcJXmHGvH_zuzjqiBKp4G=SmKyx=R_-A@mail.gmail.com>
Date:   Tue, 16 Aug 2022 22:38:34 -0700
From:   Peter Collingbourne <pcc@...gle.com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Evgenii Stepanov <eugenis@...gle.com>,
        Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mte: Follow arm64.nomte override in MMU setup.

On Tue, Aug 16, 2022 at 12:51 AM Catalin Marinas
<catalin.marinas@....com> wrote:
>
> On Tue, Aug 09, 2022 at 06:24:23PM -0700, Peter Collingbourne wrote:
> > On Tue, Aug 9, 2022 at 10:29 AM Evgenii Stepanov <eugenis@...gle.com> wrote:
> > > On Tue, Aug 9, 2022 at 9:49 AM Marc Zyngier <maz@...nel.org> wrote:
> > > > In which case what is the tag memory doing in the linear map?
> > > > Shouldn't it be marked as reserved, not mapped, and in general
> > > > completely ignored by the NS OS?
> > >
> > > That would be wasteful. The idea is to only reserve the parts of the
> > > tag memory that correspond to the TZ carveout and release the rest to
> > > the NS OS.
> >
> > More generally, one can imagine a system where *any* tagged memory
> > transaction can result in an SError because the MTE implementation was
> > not configured by an earlier bootloader phase, e.g. because the
> > bootloader was configured to disable MTE at runtime. On such systems,
> > the kernel must refrain from causing tagged memory transactions to be
> > issued via the linear map, and that's exactly what this patch does.
>
> The problem is that it doesn't. The 8.5 architecture allows any Normal
> Cacheable (even non-tagged) mapping to fetch tags. It may happen that on
> certain implementations setting MAIR to non-tagged works but that's not
> guaranteed and with the Linux kernel we tend to stick to the architected
> behaviour (with a few exceptions like PMU counters and errata).
>
> There is an ongoing discussion with the architects and partners on
> whether we can tighten the architecture as not to cause visible
> side-effects like SError but not sure whether that has been closed yet
> (just back from holiday).
>
> Until that's sorted, tag storage cannot be reused in an arm64-generic
> way in the kernel.

We can see how that discussion turns out, but let me take a shot at
persuading you that this is the right thing to do in any case.

Again, this isn't necessarily about reusing tag storage. It's about
whether the accesses via the linear map are expected to work at all.
As defined, the architecture gives EL2 the role of controlling whether
the system is deemed to implement, among other features, FEAT_MTE2, as
there is no capability for EL3 to trap accesses to the relevant ID
register. On the other hand, EL3 does to a large extent control
whether FEAT_MTE2 is implemented on a particular system, regardless of
whether the CPUs are capable of supporting it. Therefore, the kernel
has pragmatically defined arm64.nomte, together with other command
line arguments like arm64.nopauth, arm64.nobti and arm64.nosve, as
non-architectured means of overriding ID register bits. If the
relevant ID register bits for MTE as filtered through the command line
arguments are 0, this implies that FEAT_MTE2 is not implemented.

At this point we rejoin what is architected. Among the features
implied by FEAT_MTE2 is the ability to assign the Tagged Normal
attribute to pages via the MAIR. If the kernel were to use the Tagged
Normal attribute anyway, the behavior is defined to be UNPREDICTABLE.
Therefore, the kernel must not use this attribute in order to avoid
UNPREDICTABLE behavior. It is simply a bug that we are failing to
respect arm64.nomte when computing the MAIR.

Peter

Powered by blists - more mailing lists