linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: stable@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v4.4 backport 11/16] powerpc/64s: Add support for RFI flush of L1-D cache
Date: Sun, 4 Feb 2018 12:00:39 +0100	[thread overview]
Message-ID: <20180204110039.GH7519@kroah.com> (raw)
In-Reply-To: <20180204050010.13669-12-mpe@ellerman.id.au>

On Sun, Feb 04, 2018 at 04:00:05PM +1100, Michael Ellerman wrote:
> commit aa8a5e0062ac940f7659394f4817c948dc8c0667 upstream.
> 
> On some CPUs we can prevent the Meltdown vulnerability by flushing the
> L1-D cache on exit from kernel to user mode, and from hypervisor to
> guest.
> 
> This is known to be the case on at least Power7, Power8 and Power9. At
> this time we do not know the status of the vulnerability on other CPUs
> such as the 970 (Apple G5), pasemi CPUs (AmigaOne X1000) or Freescale
> CPUs. As more information comes to light we can enable this, or other
> mechanisms on those CPUs.
> 
> The vulnerability occurs when the load of an architecturally
> inaccessible memory region (eg. userspace load of kernel memory) is
> speculatively executed to the point where its result can influence the
> address of a subsequent speculatively executed load.
> 
> In order for that to happen, the first load must hit in the L1,
> because before the load is sent to the L2 the permission check is
> performed. Therefore if no kernel addresses hit in the L1 the
> vulnerability can not occur. We can ensure that is the case by
> flushing the L1 whenever we return to userspace. Similarly for
> hypervisor vs guest.
> 
> In order to flush the L1-D cache on exit, we add a section of nops at
> each (h)rfi location that returns to a lower privileged context, and
> patch that with some sequence. Newer firmwares are able to advertise
> to us that there is a special nop instruction that flushes the L1-D.
> If we do not see that advertised, we fall back to doing a displacement
> flush in software.
> 
> For guest kernels we support migration between some CPU versions, and
> different CPUs may use different flush instructions. So that we are
> prepared to migrate to a machine with a different flush instruction
> activated, we may have to patch more than one flush instruction at
> boot if the hypervisor tells us to.
> 
> In the end this patch is mostly the work of Nicholas Piggin and
> Michael Ellerman. However a cast of thousands contributed to analysis
> of the issue, earlier versions of the patch, back ports testing etc.
> Many thanks to all of them.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> [Balbir - back ported to stable with changes]
> Signed-off-by: Balbir Singh <bsingharora@gmail.com>

Also applied to 4.9.y

  reply	other threads:[~2018-02-04 11:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-04  4:59 [PATCH v4.4 backport 00/16] powerpc stable backports for v4.4 Michael Ellerman
2018-02-04  4:59 ` [PATCH v4.4 backport 01/16] powerpc/bpf/jit: Disable classic BPF JIT on ppc64le Michael Ellerman
2018-02-04  4:59 ` [PATCH v4.4 backport 02/16] powerpc/64: Fix flush_(d|i)cache_range() called from modules Michael Ellerman
2018-02-04  4:59 ` [PATCH v4.4 backport 03/16] powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC Michael Ellerman
2018-02-04  4:59 ` [PATCH v4.4 backport 04/16] powerpc: Simplify module TOC handling Michael Ellerman
2018-02-04  4:59 ` [PATCH v4.4 backport 05/16] powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper Michael Ellerman
2018-02-04 10:52   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 06/16] powerpc/64: Add macros for annotating the destination of rfid/hrfid Michael Ellerman
2018-02-04 10:53   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 07/16] powerpc/64s: Simple RFI macro conversions Michael Ellerman
2018-02-04 10:55   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 08/16] powerpc/64: Convert fast_exception_return to use RFI_TO_USER/KERNEL Michael Ellerman
2018-02-04  5:00 ` [PATCH v4.4 backport 09/16] powerpc/64: Convert the syscall exit path " Michael Ellerman
2018-02-04  5:00 ` [PATCH v4.4 backport 10/16] powerpc/64s: Convert slb_miss_common " Michael Ellerman
2018-02-04 10:58   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 11/16] powerpc/64s: Add support for RFI flush of L1-D cache Michael Ellerman
2018-02-04 11:00   ` Greg KH [this message]
2018-02-04  5:00 ` [PATCH v4.4 backport 12/16] powerpc/64s: Support disabling RFI flush with no_rfi_flush and nopti Michael Ellerman
2018-02-04  5:00 ` [PATCH v4.4 backport 13/16] powerpc/pseries: Query hypervisor for RFI flush settings Michael Ellerman
2018-02-04  5:00 ` [PATCH v4.4 backport 14/16] powerpc/powernv: Check device-tree " Michael Ellerman
2018-02-04 11:03   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 15/16] powerpc/64s: Wire up cpu_show_meltdown() Michael Ellerman
2018-02-04 11:06   ` Greg KH
2018-02-04  5:00 ` [PATCH v4.4 backport 16/16] powerpc/64s: Allow control of RFI flush via debugfs Michael Ellerman
2018-02-04 11:07   ` Greg KH
2018-02-04 11:07 ` [PATCH v4.4 backport 00/16] powerpc stable backports for v4.4 Greg KH

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=20180204110039.GH7519@kroah.com \
    --to=greg@kroah.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --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;
as well as URLs for NNTP newsgroup(s).