Page MenuHomeFreeBSD

Add arm64 pointer authentication support
Needs ReviewPublic

Authored by andrew on Wed, Jul 21, 3:32 PM.

Details

Reviewers
manu
kib
markj
Group Reviewers
arm64
Summary

Pointer authentication allows userspace to add instructions to insert
a Pointer Authentication Code (PAC) into a register based on an address
and modifier and check if the PAC is correct. If the check fails it will
either return an invalid address or fault to the kernel.

As many of these instructions are a NOP when disabled and in earlier
revisions of the architecture this can be used, for example, to sign
the return address before pushing it to the stack making Return-oriented
programming (ROP) attack more difficult on hardware that supports them.

The kernel manages five 128 bit signing keys: 2 instruction keys, 2 data
keys, and a generic key. The instructions then use one of these when
signing the registers. Instructions that use the first four store the
PAC in the register being signed, however the instructions that use the
generic key store the PAC in a separate register.

Currently all userspace threads share all the keys within a process
with a new set of userspace keys being generated when executing a new
process. This means a forked child will share its keys with its parent
until it calls an appropriate exec system call.

In the kernel we allow the use of one of the instruction keys, the ia
key. This will be used to sign return addresses in function calls.
Unlike userspace each kernel thread has its own randomly generated.

Thread0 has a static key as does the early code on secondary CPUs.
This should be safe as there is minimal user interaction with these
threads, however we could generate random keys when the Armv8.5
Random number generation instructions are present.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 40601
Build 37490: arc lint + arc unit

Event Timeline

Is this significant enough to warrant a config option to turn it off (or maybe a tunable)?

sys/arm64/arm64/locore.S
148

This could benefit from a comment about why initarm doesn't just call ptrauth_start (obvious once you see the problem, but not if you don't...)

sys/arm64/arm64/ptrauth.c
228