From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/11] ARMv8.3 pointer authentication userspace support
Date: Wed, 19 Jul 2017 17:01:21 +0100 [thread overview]
Message-ID: <1500480092-28480-1-git-send-email-mark.rutland@arm.com> (raw)
This series adds support for the ARMv8.3 pointer authentication extension.
Since RFC [1]:
* Make the KVM context switch (semi-lazy)
* Rebase to v4.13-rc1
* Improve pointer authentication documentation
* Add hwcap documentation
* Various minor cleanups
I've pushed the series to the arm64/pointer-auth branch [2] of my linux tree.
I've also pushed out a necessary bootwrapper patch to the pointer-auth branch
[3] of my bootwrapper repo.
Extension Overview
==================
The ARMv8.3 pointer authentication extension adds functionality to detect
modification of pointer values, mitigating certain classes of attack such as
stack smashing, and making return oriented programming attacks harder
The extension introduces the concept of a pointer authentication code (PAC),
which is stored in some upper bits of pointers. Each PAC is derived from the
original pointer, another 64-bit value (e.g. the stack pointer), and a secret
128-bit key.
New instructions are added which can be used to:
* Insert a PAC into a pointer
* Strip a PAC from a pointer
* Authenticate strip a PAC from a pointer
If authentication succeeds, the code is removed, yielding the original pointer.
If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.
These instructions can make use of four keys:
* APIAKey (A.K.A. Instruction A key)
* APIBKey (A.K.A. Instruction B key)
* APDAKey (A.K.A. Data A key)
* APDBKey (A.K.A. Data B Key)
A subset of these instruction encodings have been allocated from the HINT
space, and will operate as NOPs on any ARMv8 parts which do not feature the
extension (or if purposefully disabled by the kernel). Software using only this
subset of the instructions should function correctly on all ARMv8-A parts.
Additionally, instructions are added to authenticate small blocks of memory in
similar fashion, using APGAKey (A.K.A. Generic key).
This Series
===========
This series enables the use of instructions using APIAKey, which is initialised
and maintained per-process (shared by all threads). This series does not add
support for APIBKey, APDAKey, APDBKey, nor APGAKey. The series only supports
the use of an architected algorithm.
I've given this some basic testing with a homebrew test suite. More ideally,
we'd add some tests to the kernel source tree.
I've added some basic KVM support, but this doesn't cater for systems with
mismatched support. Looking forward, we'll need ID register emulation in KVM so
that we can hide features from guests to cater for such cases.
Open questions
==============
* Should keys be per-thread rather than per-process?
My understanding is that glibc can't (currently) handle threads having
different keys, but it might be that another libc would prefer per-thread
keys. If desired, we could add a mechanism for a thread to re-initialize its
keys without an exec*().
* Do we need a separate hwcap for XPAC* instructions?
Library code performing stack unwinding may need to interoperate with other
code which may or may not be using pointer authentication. It may be
desirable to use XPAC* rather than attempting authentication and/or acquiring
the PAC masks via ptrace.
As we may expose APIBKey (potentially separately from APIAKey) in future,
HWCAP_APIA cannot be used to determine when these instruction can/should be
used.
* Should we expose a per-process data key now, to go with the insn key?
I don't currently have a use-case for this.
* Should we expose generic authentication (i.e. APGAKey)?
I don't currently have a use-case for this.
* Should the kernel remove PACs when unwinding user stacks?
This is simple to do, but it's arguably placing a policy in the kernel as to
what we expect user stacks to look like. Regardless, userspace will have to
perform this when unwinding with DWARF.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/498941.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/pointer-auth
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/boot-wrapper-aarch64.git pointer-auth
Mark Rutland (11):
arm64: docs: describe ELF hwcaps
asm-generic: mm_hooks: allow hooks to be overridden individually
arm64: add pointer authentication register bits
arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits
arm64/cpufeature: detect pointer authentication
arm64: Don't trap host pointer auth use to EL2
arm64: add basic pointer authentication support
arm64: expose user PAC bit positions via ptrace
arm64/kvm: preserve host HCR_EL2 value
arm64/kvm: context-switch ptrauth registers
arm64: docs: document pointer authentication
Documentation/arm64/booting.txt | 8 ++
Documentation/arm64/elf_hwcaps.txt | 138 +++++++++++++++++++++++++
Documentation/arm64/pointer-authentication.txt | 85 +++++++++++++++
arch/arm64/Kconfig | 23 +++++
arch/arm64/include/asm/cpucaps.h | 4 +-
arch/arm64/include/asm/esr.h | 3 +-
arch/arm64/include/asm/kvm_arm.h | 3 +-
arch/arm64/include/asm/kvm_host.h | 28 ++++-
arch/arm64/include/asm/kvm_hyp.h | 7 ++
arch/arm64/include/asm/mmu.h | 5 +
arch/arm64/include/asm/mmu_context.h | 25 ++++-
arch/arm64/include/asm/pointer_auth.h | 97 +++++++++++++++++
arch/arm64/include/asm/sysreg.h | 30 ++++++
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/include/uapi/asm/ptrace.h | 5 +
arch/arm64/kernel/cpufeature.c | 39 ++++++-
arch/arm64/kernel/cpuinfo.c | 1 +
arch/arm64/kernel/head.S | 19 +++-
arch/arm64/kernel/ptrace.c | 39 +++++++
arch/arm64/kvm/handle_exit.c | 21 ++++
arch/arm64/kvm/hyp/Makefile | 1 +
arch/arm64/kvm/hyp/ptrauth-sr.c | 91 ++++++++++++++++
arch/arm64/kvm/hyp/switch.c | 9 +-
arch/arm64/kvm/hyp/tlb.c | 6 +-
arch/arm64/kvm/sys_regs.c | 32 ++++++
include/asm-generic/mm_hooks.h | 11 ++
include/uapi/linux/elf.h | 1 +
27 files changed, 719 insertions(+), 13 deletions(-)
create mode 100644 Documentation/arm64/elf_hwcaps.txt
create mode 100644 Documentation/arm64/pointer-authentication.txt
create mode 100644 arch/arm64/include/asm/pointer_auth.h
create mode 100644 arch/arm64/kvm/hyp/ptrauth-sr.c
--
1.9.1
next reply other threads:[~2017-07-19 16:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-19 16:01 Mark Rutland [this message]
2017-07-19 16:01 ` [PATCH 01/11] arm64: docs: describe ELF hwcaps Mark Rutland
2017-07-21 17:05 ` Dave Martin
2017-07-24 10:47 ` Suzuki K Poulose
2017-08-03 14:49 ` Catalin Marinas
2017-08-03 17:57 ` Kees Cook
2017-07-19 16:01 ` [PATCH 02/11] asm-generic: mm_hooks: allow hooks to be overridden individually Mark Rutland
2017-07-19 16:01 ` [PATCH 03/11] arm64: add pointer authentication register bits Mark Rutland
2017-07-19 16:01 ` [PATCH 04/11] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits Mark Rutland
2017-07-24 10:54 ` Suzuki K Poulose
2017-07-19 16:01 ` [PATCH 05/11] arm64/cpufeature: detect pointer authentication Mark Rutland
2017-07-19 16:01 ` [PATCH 06/11] arm64: Don't trap host pointer auth use to EL2 Mark Rutland
2017-07-24 10:37 ` Dave Martin
2017-07-19 16:01 ` [PATCH 07/11] arm64: add basic pointer authentication support Mark Rutland
2017-07-25 15:26 ` Dave Martin
2017-08-11 7:46 ` Yao Qi
2017-08-11 8:45 ` Dave Martin
2017-07-19 16:01 ` [PATCH 08/11] arm64: expose user PAC bit positions via ptrace Mark Rutland
2017-07-19 16:01 ` [PATCH 09/11] arm64/kvm: preserve host HCR_EL2 value Mark Rutland
2017-08-01 11:00 ` Christoffer Dall
2017-07-19 16:01 ` [PATCH 10/11] arm64/kvm: context-switch ptrauth registers Mark Rutland
2017-08-01 11:00 ` Christoffer Dall
2017-08-01 14:26 ` Mark Rutland
2017-08-01 14:32 ` Will Deacon
2017-08-01 17:02 ` Christoffer Dall
2017-07-19 16:01 ` [PATCH 11/11] arm64: docs: document pointer authentication Mark Rutland
2017-07-21 17:05 ` [PATCH 00/11] ARMv8.3 pointer authentication userspace support Dave Martin
2017-07-25 12:06 ` Mark Rutland
2017-07-25 14:00 ` Jiong Wang
2017-08-11 11:29 ` Mark Rutland
2017-07-24 11:52 ` Yao Qi
2017-07-25 11:32 ` Yao Qi
2017-07-25 16:01 ` Mark Rutland
2017-07-25 14:12 ` [kernel-hardening] " Li Kun
2017-07-25 15:12 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1500480092-28480-1-git-send-email-mark.rutland@arm.com \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).