[5.9,0/5] CVE-2020-4788: Speculation on incompletely validated data on IBM Power9

IBM Power9 processors can speculatively operate on data in the L1
cache before it has been completely validated, via a way-prediction
mechanism. It is not possible for an attacker to determine the
contents of impermissible memory using this method, since these
systems implement a combination of hardware and software security
measures to prevent scenarios where protected data could be leaked.

However these measures don't address the scenario where an attacker
induces the operating system to speculatively execute instructions
using data that the attacker controls. This can be used for example to
speculatively bypass "kernel user access prevention" techniques, as
discovered by Anthony Steinhauser of Google's Safeside Project. This
is not an attack by itself, but there is a possibility it could be
used in conjunction with side-channels or other weaknesses in the
privileged code to construct an attack.

This issue can be mitigated by flushing the L1 cache between privilege
boundaries of concern. This series flushes the cache on kernel entry and
after kernel user accesses.

Thanks to Nick Piggin, Russell Currey, Christopher M. Riedl, Michael
Ellerman and Spoorthy S for their work in developing, optimising,
testing and backporting these fixes, and to the many others who helped
behind the scenes.

Daniel Axtens (1):
  selftests/powerpc: entry flush test

Michael Ellerman (1):
  powerpc: Only include kup-radix.h for 64-bit Book3S

Nicholas Piggin (2):
  powerpc/64s: flush L1D on kernel entry
  powerpc/64s: flush L1D after user accesses

Russell Currey (1):
  selftests/powerpc: rfi_flush: disable entry flush if present

 .../admin-guide/kernel-parameters.txt         |   7 +
 .../powerpc/include/asm/book3s/64/kup-radix.h |  66 +++---
 arch/powerpc/include/asm/exception-64s.h      |  12 +-
 arch/powerpc/include/asm/feature-fixups.h     |  19 ++
 arch/powerpc/include/asm/kup.h                |  26 ++-
 arch/powerpc/include/asm/security_features.h  |   7 +
 arch/powerpc/include/asm/setup.h              |   4 +
 arch/powerpc/kernel/exceptions-64s.S          |  80 +++----
 arch/powerpc/kernel/setup_64.c                | 122 ++++++++++-
 arch/powerpc/kernel/syscall_64.c              |   2 +-
 arch/powerpc/kernel/vmlinux.lds.S             |  14 ++
 arch/powerpc/lib/feature-fixups.c             | 104 +++++++++
 arch/powerpc/platforms/powernv/setup.c        |  17 ++
 arch/powerpc/platforms/pseries/setup.c        |   8 +
 .../selftests/powerpc/security/.gitignore     |   1 +
 .../selftests/powerpc/security/Makefile       |   2 +-
 .../selftests/powerpc/security/entry_flush.c  | 198 ++++++++++++++++++
 .../selftests/powerpc/security/rfi_flush.c    |  35 +++-
 18 files changed, 646 insertions(+), 78 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/security/entry_flush.c

On Fri, Nov 20, 2020 at 10:22:45AM +1100, Daniel Axtens wrote:
> IBM Power9 processors can speculatively operate on data in the L1

> cache before it has been completely validated, via a way-prediction

> mechanism. It is not possible for an attacker to determine the

> contents of impermissible memory using this method, since these

> systems implement a combination of hardware and software security

> measures to prevent scenarios where protected data could be leaked.

> 

> However these measures don't address the scenario where an attacker

> induces the operating system to speculatively execute instructions

> using data that the attacker controls. This can be used for example to

> speculatively bypass "kernel user access prevention" techniques, as

> discovered by Anthony Steinhauser of Google's Safeside Project. This

> is not an attack by itself, but there is a possibility it could be

> used in conjunction with side-channels or other weaknesses in the

> privileged code to construct an attack.

> 

> This issue can be mitigated by flushing the L1 cache between privilege

> boundaries of concern. This series flushes the cache on kernel entry and

> after kernel user accesses.

> 

> Thanks to Nick Piggin, Russell Currey, Christopher M. Riedl, Michael

> Ellerman and Spoorthy S for their work in developing, optimising,

> testing and backporting these fixes, and to the many others who helped

> behind the scenes.


All of these for all branches are now queued up, thanks for making them
so easy to apply!

greg k-h