Re: [kernel-hardening] [PATCH 00/11] ARMv8.3 pointer authentication userspace support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mark,

Could you please give us some information about the impact to performance to help us evaluating

the influence to the system?

Thanks a lot.


Best Regards


在 2017/7/20 0:01, Mark Rutland 写道:
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


--
Best Regards
Li Kun




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux