1.. SPDX-License-Identifier: GPL-2.0-or-later 2 3========================================== 4DEXCR (Dynamic Execution Control Register) 5========================================== 6 7Overview 8======== 9 10The DEXCR is a privileged special purpose register (SPR) introduced in 11PowerPC ISA 3.1B (Power10) that allows per-cpu control over several dynamic 12execution behaviours. These behaviours include speculation (e.g., indirect 13branch target prediction) and enabling return-oriented programming (ROP) 14protection instructions. 15 16The execution control is exposed in hardware as up to 32 bits ('aspects') in 17the DEXCR. Each aspect controls a certain behaviour, and can be set or cleared 18to enable/disable the aspect. There are several variants of the DEXCR for 19different purposes: 20 21DEXCR 22 A privileged SPR that can control aspects for userspace and kernel space 23HDEXCR 24 A hypervisor-privileged SPR that can control aspects for the hypervisor and 25 enforce aspects for the kernel and userspace. 26UDEXCR 27 An optional ultravisor-privileged SPR that can control aspects for the ultravisor. 28 29Userspace can examine the current DEXCR state using a dedicated SPR that 30provides a non-privileged read-only view of the userspace DEXCR aspects. 31There is also an SPR that provides a read-only view of the hypervisor enforced 32aspects, which ORed with the userspace DEXCR view gives the effective DEXCR 33state for a process. 34 35 36Configuration 37============= 38 39The DEXCR is currently unconfigurable. All threads are run with the 40NPHIE aspect enabled. 41 42 43coredump and ptrace 44=================== 45 46The userspace values of the DEXCR and HDEXCR (in this order) are exposed under 47``NT_PPC_DEXCR``. These are each 64 bits and readonly, and are intended to 48assist with core dumps. The DEXCR may be made writable in future. The top 32 49bits of both registers (corresponding to the non-userspace bits) are masked off. 50 51If the kernel config ``CONFIG_CHECKPOINT_RESTORE`` is enabled, then 52``NT_PPC_HASHKEYR`` is available and exposes the HASHKEYR value of the process 53for reading and writing. This is a tradeoff between increased security and 54checkpoint/restore support: a process should normally have no need to know its 55secret key, but restoring a process requires setting its original key. The key 56therefore appears in core dumps, and an attacker may be able to retrieve it from 57a coredump and effectively bypass ROP protection on any threads that share this 58key (potentially all threads from the same parent that have not run ``exec()``). 59