The 64-bit Arm architecture (a.k.a. "arm64", "aarch64") defines a large quantity of special system registers. Many of them are inaccessible from userland. When a system register name ends in _EL1, it is accessible only at EL1 (kernel mode). Similarly, system registers in _EL2 are accessible only in hypervisor mode and _EL3 in monitor mode.

This educational project provides a way to return the exact content of a few Arm64 system registers to userland through a dedicated loadable kernel module, on Linux, macOS, and Windows. Some application programs are provided to display an analysis of the contents of these registers.

More generally, this project provides some notes, examples, and information on the the Arm64 architecture for developers.

Contents:

• Accessing the system registers
• Build instructions
• Usage instructions
• Focus on Pointer Authentication Code (PAC)
• List of accessible registers

Reading and writing system registers is done using the special instructions MRS and MSR, respectively. Each system register has a dedicated exception level, EL0 to EL3. Trying to access a system register from an outer level results in an "illegal instruction" exception.

On Linux, there is a special feature in the kernel which allows a limited access to a few _EL1 system registers from user mode (EL0). The kernel intercepts the SIGILL exception which results from the invalid access to a system register using an MRS instruction. If the requested system register is one of a few selected allowed registers, the kernel reads the system register and returns it to the process, as if the MRS instruction executed correctly.

This is explained in details here. As a general requirement, no sensitive security information is returned. In some cases, some parts of the register content are blacked out.

This is a Linux-only feature and it is limited to a few registers, or a subpart of them. This means that we are never really sure of what the physical register was.

This project provides Linux, macOS, and Windows kernel modules to read and write selected system registers from user applications.

Warning: This project is for educational purpose only, for people wanting to increase their knowledge in the Arm64 architecture. Loading a custom kernel module may always have unexpected side effects, including:

• Security effects: the content of the system registers could be used to gain information on the system, including the pointer authentication keys on Linux (they are better protected on macOS).
• Stability effects:
  • Accessing Arm system registers is not only a matter of exception level. The Arm architecture reference manual describes in details the pseudo-code to access each register. There are many specific configuration options, usually set by the hypervisor (EL2) or monitor (EL3) which filter or protect access to the register. In specific configurations, depending on the operating system or the platform, accessing a system register from the kernel may either work or crash the system.
  • Modifying the PACIA key using a kernel which is built with pointer authentication crashes the system since the return pointer of the kernel functions are authenticated with a different key as used by the previous PACIA (believe me, I tried...)

See the file docs/references.md for a list of reference documentations on the Arm64 architecture, its system registers and pointer authentication features.

For Linux and macOS:

• make : Build the kernel module and the applications.
• make install : Install the kernel module in the system tree.
• make load : Load the kernel module.
• make unload : Unload the kernel module.
• make show : Show the loaded kernel module.

For Windows, see the directory msbuild.

See also more details in the README files of the apps and kernel subdirectories.

The C application sysregs is a generic tool to read and write the system registers. With option -v (verbose), most system registers are structured using bit-fields of various sizes and interpretation.

Syntax: sysregs [options]

  -r name       : read the content of the named register
  -w name value : write the specified hexadecimal value in the named register
  -d name value : display the specified value in the named register format

  -a : read all supported Arm64 system registers
  -b : display register value in binary (default: hex)
  -f : force read/write register, even if not supposed to (risk of system crash)
  -h : display this help text
  -l : list the names of all supported Arm64 system registers
  -p : summary of supported PAC features
  -s : summary of CPU features
  -S : same as -s but read registers at EL0 (maybe partial, may fail)
  -v : verbose, display register analysis and fields

See more details in:

• The apps subdirectory for other command line tools.
• The kernel subdirectory for programming guidelines.

One of the motivations for this project was a better understanding of the Pointer Authentication Code (PAC) feature, as introduced in the Armv8.3-A architecture. PAC is one of the clever "defensive security" features which were designed by Arm (the other one is BTI, the Branch Target Indentification in Armv8.5-A).

Understanding PAC is harder than it may seem. There are many configuration options which depend on the operating system or the platform. Predicting the size, position and value of a PAC is not trivial. We need to read several memory management system registers and correctly interpret the complex Arm pseudo-code (or emulate it as done in this project). The command sysregs -p summarizes this.

There are several documents in the docs subdirectory containing the summary of observations about the PAC on different platforms. The subdirectory collect contains informations which were collected on these platforms, Linux, macOS, Windows, using various Arm64-based processor chips implementing Armv8.3-A or higher versions of the architecture.

Specifically, this project was the main tool to support the writing of the white paper "Control Flow Integrity, anti-malware active protection on Arm64 systems" from SiPearl.

The reference list of registers which can be accessed by this project is given by the list of CSR_REG_xxx and CSR_REG2_xxx constants in file kernel/cpusysregs.h.

Some _EL0 registers can be protected by the kernel using _EL1 control registers. Reading these _EL0 registers in user mode raises an illegal instruction exception. In that case, they can be accessed from kernel mode using the kernel module.

[1] The Pointer Authentication Key registers are usually readable and writeable at EL1 (kernel). This is the case on Linux. On macOS, however, in the default configuration, the PAC key registers can be accessed at EL3 only. This is explained in file docs/arm64e-on-macos.md. Accessing the PAC key registers at EL1 crashes macOS.

[2] HCR_EL2 is readable at EL1 on macOS. Access not allowed in a Linux VM and crashes the system.

[3] SCR_EL3 cannot by read/write at EL1. It is supported to format its possible values only.

[4] PMSIDR_EL1 cannot be read on Linux at EL1, even when FEAT_SPE is implemented.

[5] These registers cannot be accessed on Windows. Reading or writing them crashes the system.