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]
Message-ID: <20230918100102.GA17472@willie-the-truck>
Date:   Mon, 18 Sep 2023 11:01:02 +0100
From:   Will Deacon <will@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     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 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.

Anyway, hopefully I'm barking up the wrong tree, but it would be helpful
to have some intuition behind the workaround in order to review (and
maintain) this patch.

Cheers,

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ