linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	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
Subject: Re: [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative unprivileged load workaround
Date: Tue, 19 Sep 2023 13:49:55 +0100	[thread overview]
Message-ID: <86zg1icop8.wl-maz@kernel.org> (raw)
In-Reply-To: <CAL_JsqLXBDaAUKDjRCyiuZeR4khxKzN5Q2_LhUPg34YDGpjmGg@mail.gmail.com>

On Tue, 19 Sep 2023 13:29:07 +0100,
Rob Herring <robh@kernel.org> wrote:
> 
> On Mon, Sep 18, 2023 at 5:18 AM Marc Zyngier <maz@misterjones.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?

No, EL2 is always mapped, and we don't have anything like KPTI there.

Maybe the saving grace is that EL2 and EL2&0 are different translation
regimes from EL1&0, but there's nothing in the commit message that
indicates it. As for EL1-to-EL1 leaks, it again completely depends on
how the TLBs are tagged.

You'd hope that having different VMIDs would save the bacon, but if
you can leak EL1 translations into EL0, it means that the associated
permission and/or tags do not contain all the required information...

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-09-19 12:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230912121120.380420-1-robh@kernel.org>
2023-09-12 12:11 ` [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Rob Herring
2023-09-18 10:01   ` Will Deacon
2023-09-18 10:17     ` Marc Zyngier
2023-09-19 12:29       ` Rob Herring
2023-09-19 12:49         ` Marc Zyngier [this message]
2023-09-20 16:47           ` Rob Herring
2023-09-20 17:17             ` Marc Zyngier
2023-09-19 12:21     ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86zg1icop8.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).