| Message ID | 20221128024458.46121-1-bgray@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add DEXCR support | expand |
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
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? * 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? * 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. * 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. * 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). 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