Message-ID: <5fc3102ef379d2a34d64cfea93ce7599e0fd640f.camel@russell.cc>
Date:   Mon, 28 Nov 2022 15:05:08 +1100
From:   Russell Currey <ruscur@...sell.cc>
To:     Benjamin Gray <bgray@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org
Cc:     ajd@...ux.ibm.com, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org, cmr@...escreens.de
Subject: Re: [RFC PATCH 00/13] Add DEXCR support

On Mon, 2022-11-28 at 13:44 +1100, Benjamin Gray wrote:
> This series is based on initial work by Chris Riedl that was not sent
> to the list.
> 
> Adds a kernel interface for userspace to interact with the DEXCR.
> The DEXCR is a SPR that allows control over various execution
> 'aspects', such as indirect branch prediction and enabling the
> hashst/hashchk instructions. Further details are in ISA 3.1B
> Book 3 chapter 12.
> 
> This RFC proposes an interface for users to interact with the DEXCR.
> It aims to support
> 
> * Querying supported aspects
> * Getting/setting aspects on a per-process level
> * Allowing global overrides across all processes
> 
> There are some parts that I'm not sure on the best way to approach
> (hence RFC):
> 
> * The feature names in arch/powerpc/kernel/dt_cpu_ftrs.c appear to be
> unimplemented
>   in skiboot, so are being defined by this series. Is being so
> verbose fine?

These are going to need to be added to skiboot before they can be
referenced in the kernel.  Inclusion in skiboot makes them ABI, the
kernel is just a consumer.

> * What aspects should be editable by a process? E.g., SBHE has
>   effects that potentially bleed into other processes. Should
>   it only be system wide configurable?

For context, ISA 3.1B p1358 says: 

   In some micro-architectures, the execution behav-
   ior controlled by aspect 0 is difficult to change with
   any degree of timing precision. The change may
   also bleed over into other threads on the same pro-
   cessor. Any environment that has a dependence on
   the more secure setting of aspect 0 should not
   change the value, and ideally should share a pro-
   cessor only with similar threads. For other environ-
   ments, changes to the effective value of aspect 0
   represent a relative risk tolerance for its aspect of
   execution behavior, with the understanding that
   there will be significant hysteresis in the execution
   behavior.
   
If a process sets SBHE for itself and all it takes is context switching
from a process with SBHE unset to cause exposure, then yeah I think it
should just be global.  I doubt branch hints have enough impact for
process granularity to be especially desirable anyway.

> * Should configuring certain aspects for the process be non-
> privileged? E.g.,
>   Is there harm in always allowing configuration of IBRTPD, SRAPD?
> The *FORCE_SET*
>   action prevents further process local changes regardless of
> privilege.

I'm not aware of a reason why it would be a problem to allow
unprivileged configuration as long as there's a way to prevent further
changes.  The concerning case is if a mitigation is set by a trusted
process context, and then untrusted code is executed that manages to
turn the mitigation off again.

> * The tests fail Patchwork CI because of the new prctl macros, and
> the CI
>   doesn't run headers_install and add -isystem
> <buildpath>/usr/include to
>   the make command.

The CI runs on x86 and cross compiles the kernel and selftests, and
boots are done in qemu tcg.  Maybe we can skip the build if the symbols
are undefined or do something like

	#ifndef PR_PPC_DEXCR_...
		return KSFT_SKIP;
	#endif

in the test itself?

> * On handling an exception, I don't check if the NPHIE bit is enabled
> in the DEXCR.
>   To do so would require reading both the DEXCR and HDEXCR, for
> little gain (it
>   should only matter that the current instruction was a hashchk. If
> so, the only
>   reason it would cause an exception is the failed check. If the
> instruction is
>   rewritten between exception and check we'd be wrong anyway).

For context, the hashst and hashchk instructions are implemented using
previously reserved nops.  I'm not aware of any reason a nop could trap
(i.e. we could check for a trap that came from hashchk even if NPHIE is
not set), but afaik that'd be the only reason we would have to check.

> 
> The series is based on the earlier selftest utils series[1], so the
> tests won't build
> at all without applying that first. The kernel side should build fine
> on ppc/next
> 247f34f7b80357943234f93f247a1ae6b6c3a740 though.
> 
> [1]:
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20221122231103.15829-1-bgray@linux.ibm.com/
> 
> Benjamin Gray (13):
>   powerpc/book3s: Add missing <linux/sched.h> include
>   powerpc: Add initial Dynamic Execution Control Register (DEXCR)
>     support
>   powerpc/dexcr: Handle hashchk exception
>   powerpc/dexcr: Support userspace ROP protection
>   prctl: Define PowerPC DEXCR interface
>   powerpc/dexcr: Add prctl implementation
>   powerpc/dexcr: Add sysctl entry for SBHE system override
>   powerpc/dexcr: Add enforced userspace ROP protection config
>   selftests/powerpc: Add more utility macros
>   selftests/powerpc: Add hashst/hashchk test
>   selftests/powerpc: Add DEXCR prctl, sysctl interface test
>   selftests/powerpc: Add DEXCR status utility lsdexcr
>   Documentation: Document PowerPC kernel DEXCR interface
> 
>  Documentation/powerpc/dexcr.rst               | 183 +++++++++++
>  Documentation/powerpc/index.rst               |   1 +
>  arch/powerpc/Kconfig                          |   5 +
>  arch/powerpc/include/asm/book3s/64/kexec.h    |   6 +
>  arch/powerpc/include/asm/book3s/64/kup.h      |   1 +
>  arch/powerpc/include/asm/cputable.h           |   8 +-
>  arch/powerpc/include/asm/ppc-opcode.h         |   1 +
>  arch/powerpc/include/asm/processor.h          |  33 ++
>  arch/powerpc/include/asm/reg.h                |   7 +
>  arch/powerpc/kernel/Makefile                  |   1 +
>  arch/powerpc/kernel/dexcr.c                   | 310
> ++++++++++++++++++
>  arch/powerpc/kernel/dt_cpu_ftrs.c             |   4 +
>  arch/powerpc/kernel/process.c                 |  31 +-
>  arch/powerpc/kernel/prom.c                    |   4 +
>  arch/powerpc/kernel/traps.c                   |   6 +
>  include/uapi/linux/prctl.h                    |  14 +
>  kernel/sys.c                                  |  16 +
>  tools/testing/selftests/powerpc/Makefile      |   1 +
>  .../selftests/powerpc/dexcr/.gitignore        |   3 +
>  .../testing/selftests/powerpc/dexcr/Makefile  |  11 +
>  tools/testing/selftests/powerpc/dexcr/cap.c   |  72 ++++
>  tools/testing/selftests/powerpc/dexcr/cap.h   |  18 +
>  tools/testing/selftests/powerpc/dexcr/dexcr.c | 118 +++++++
>  tools/testing/selftests/powerpc/dexcr/dexcr.h |  54 +++
>  .../selftests/powerpc/dexcr/dexcr_test.c      | 241 ++++++++++++++
>  .../selftests/powerpc/dexcr/hashchk_test.c    | 229 +++++++++++++
>  .../testing/selftests/powerpc/dexcr/lsdexcr.c | 178 ++++++++++
>  tools/testing/selftests/powerpc/include/reg.h |   4 +
>  .../testing/selftests/powerpc/include/utils.h |  44 +++
>  29 files changed, 1602 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/powerpc/dexcr.rst
>  create mode 100644 arch/powerpc/kernel/dexcr.c
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/.gitignore
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/Makefile
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/cap.c
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/cap.h
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/dexcr.c
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/dexcr.h
>  create mode 100644
> tools/testing/selftests/powerpc/dexcr/dexcr_test.c
>  create mode 100644
> tools/testing/selftests/powerpc/dexcr/hashchk_test.c
>  create mode 100644 tools/testing/selftests/powerpc/dexcr/lsdexcr.c
> 
> 
> base-commit: 9dc58a6040662faaf24c8932861f485670fce7ff
> --
> 2.38.1

Powered by blists - more mailing lists