Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbdGYONd (ORCPT ); Tue, 25 Jul 2017 10:13:33 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:2107 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751651AbdGYON3 (ORCPT ); Tue, 25 Jul 2017 10:13:29 -0400 Subject: Re: [kernel-hardening] [PATCH 00/11] ARMv8.3 pointer authentication userspace support To: Mark Rutland References: <1500480092-28480-1-git-send-email-mark.rutland@arm.com> CC: , , , , , , , , , , , , , From: Li Kun Message-ID: Date: Tue, 25 Jul 2017 22:12:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1500480092-28480-1-git-send-email-mark.rutland@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.111.203.133] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.597751D0.001B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3ada5d772bf9264b0e61d09189658f92 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7169 Lines: 174 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