lkml.org 
[lkml]   [2017]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [kernel-hardening] [PATCH 00/11] ARMv8.3 pointer authentication userspace support
    From
    Date
    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

    \
     
     \ /
      Last update: 2017-07-25 16:14    [W:3.908 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site