Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
MIME-Version: 1.0
References: <20230912121120.380420-1-robh@kernel.org> <20230912121120.380420-2-robh@kernel.org>
 <20230918100102.GA17472@willie-the-truck>
In-Reply-To: <20230918100102.GA17472@willie-the-truck>
From:   Rob Herring <robh@kernel.org>
Date:   Tue, 19 Sep 2023 07:21:40 -0500
Message-ID: <CAL_JsqLZTHsUuET0=MEF+1RC_+YqzcY5Ba9ztKJ3jX7K9hmcMw@mail.gmail.com>
Subject: Re: [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative
 unprivileged load workaround
To:     Will Deacon <will@kernel.org>
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Jonathan Corbet <corbet@lwn.net>,
        James Morse <james.morse@arm.com>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-doc@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Sep 18, 2023 at 5:01=E2=80=AFAM Will Deacon <will@kernel.org> wrote=
:
>
> On Tue, Sep 12, 2023 at 07:11:15AM -0500, Rob Herring wrote:
> > Implement the workaround for ARM Cortex-A520 erratum 2966298. On an
> > affected Cortex-A520 core, a speculatively executed unprivileged load
> > might leak data from a privileged level via a cache side channel.
> >
> > The workaround is to execute a TLBI before returning to EL0. A
> > non-shareable TLBI to any address is sufficient.
>
> Can you elaborate at all on how this works, please?

Here's the write-up if you haven't read that already:

https://developer.arm.com/documentation/SDEN-2444153/0500/?lang=3Den

> A TLBI addressing a
> cache side channel feels weird (or is "cache" referring to some TLB
> structures rather than e.g. the data cache here?).

AIUI, the TLBI is simply enough to ensure the permission check happens
on the speculative load. It has nothing to do with actual TLB
contents.

This core has FEAT_E0PD and FEAT_CSV3 which should mitigate this
scenario, but this case is a narrow uarch condition which bypasses
those checks.

> Assuming there's some vulnerable window between the speculative
> unprivileged load and the completion of the TLBI, what prevents another
> CPU from observing the side-channel during that time?

The cache hit is private to the core. How would another core observe that?

> Also, does the
> TLBI need to be using the same ASID as the unprivileged load? If so, then
> a context-switch could widen the vulnerable window quite significantly.

No, the TLBI can be any context and/or address including unused addresses.

Rob