Date: Tue, 25 Jul 2017 22:12:24 +0800 From: Li Kun <hw.likun@...wei.com> To: Mark Rutland <mark.rutland@....com> CC: <linux-arm-kernel@...ts.infradead.org>, <arnd@...db.de>, <catalin.marinas@....com>, <christoffer.dall@...aro.org>, <Dave.Martin@....com>, <jiong.wang@....com>, <kvmarm@...ts.cs.columbia.edu>, <linux-arch@...r.kernel.org>, <marc.zyngier@....com>, <suzuki.poulose@....com>, <will.deacon@....com>, <yao.qi@....com>, <linux-kernel@...r.kernel.org>, <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support 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 : > * 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  of my linux tree. > I've also pushed out a necessary bootwrapper patch to the pointer-auth branch >  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. > >  http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/498941.html >  git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/pointer-auth >  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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.