LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Yves-Alexis Perez <corsac@debian.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4.9 34/77] powerpc: fix build errors in stable tree
Date: Fri, 23 Feb 2018 09:31:29 +1100	[thread overview]
Message-ID: <87vaeopsfy.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <1519306335.2388.18.camel@debian.org>

Yves-Alexis Perez <corsac@debian.org> writes:
> On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
>> With the patches I just sent, for pseries and powernv, the mitigation
>> should be in place. On machines with updated firmware we'll use the
>> hardware-assisted L1 flush, otherwise we fallback to doing it in
>> software.
>
> So as of 4.9.82 meltdown is *not* addressed on those arches, but it should be
> ok in 4.9.83 or 4.9.84 depending on when the patches are merged?

As of 4.9.82 *most* of the patches to do the mitigation have been
merged.

One of them was missed, due to it not applying (because it was actually
a back port to 4.4 that was sent) that is:

  222f20f14062 ("powerpc/64s: Simple RFI macro conversions")


That patch adds calls to do the L1D cache flush when returning to
user/guest, so it is important that it's missing, the mitigation is not
fully effective without that patch.

However, 4.9.82 *does* have a backport of:

  b8e90cb7bc04 ("powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL")

So the syscall path is protected, which means any attack which uses
syscalls is likely to fail.

Because the data the attack is trying to read has to be in the L1D, you
can't write an attack that remains in userspace 100% of the time, you
have to enter the kernel and have the kernel load the target data into
the L1D for you. With the syscall flush in place you can't use a syscall
for that, you have to trigger some other kernel entry/exit, eg. a page
fault.

TLDR is with the syscall flush in place it's much harder to write an
attack.

Greg has already released 4.9.83, so hopefully 4.9.84 will be fully
protected.

Note also that 4.9.82/83 have a bug in the SLB miss handler that can
lead to hangs in userspace, fixed by the first patch I sent.

cheers

           reply	other threads:[~2018-02-22 22:31 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1519306335.2388.18.camel@debian.org>]

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=87vaeopsfy.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=corsac@debian.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=stable@vger.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