linux-kernel - Re: [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative unprivileged load workaround

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]

Date:   Tue, 19 Sep 2023 07:29:07 -0500
From:   Rob Herring <robh@...nel.org>
To:     Marc Zyngier <maz@...terjones.org>
Cc:     Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Jonathan Corbet <corbet@....net>,
        James Morse <james.morse@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative
 unprivileged load workaround

On Mon, Sep 18, 2023 at 5:18 AM Marc Zyngier <maz@...terjones.org> wrote:
>
> On 2023-09-18 11:01, Will Deacon 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? 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?).
> >
> > 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? 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.
>
> Another 'interesting' case is the KVM world switch. If EL0 is
> affected, what about EL1? Can such a data leak exist cross-EL1,
> or from EL2 to El1? Asking for a friend...

I'm checking for a definitive answer, but page table isolation also
avoids the issue. Wouldn't these scenarios all be similar to page
table isolation in that the EL2 or prior EL1 context is unmapped?

Rob