Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp191506imm; Fri, 5 Oct 2018 02:05:19 -0700 (PDT) X-Google-Smtp-Source: ACcGV63JLAFcnV3VySjjpO7oBu91VvjCJCUZgc3AG1WlMygXYZ7MWBvqV0MvZyTNcj5XCZIrO/PT X-Received: by 2002:a63:7d2:: with SMTP id 201-v6mr9480167pgh.129.1538730319416; Fri, 05 Oct 2018 02:05:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538730319; cv=none; d=google.com; s=arc-20160816; b=qCor3nrlVHC0BO5Ozs7RfToSkna21x33W+dG3IZ93yh3n5LKv3xcggVWtTEK/NYl/I I/XeqeVro2oDPBJJVBx1ejYV4Rku8ScPSenmqkT0eYfgnvVyEDEgb6VpIg4zEVOGtTIP lpP6sGlIvbX6sFaILgfX82ZbYw+nTHFya+ueqMzJ5sijvol2xDIo/gDgZuXLQ1OJupwg DebE/HNvZ1YQLiCt38bwlwFQBUKLtNOHO/Epr93wCcemkJREM0qldEyoec5lJ3yQrsR9 e+IvvUkAIDkJ8opbRqLkKSOs9y46q/whOGuM31Y/p45P72w2L7hYwvALvNfGoeADPhby Eb6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=xV7M1lez0FR0J4v9Y9yd3CgaI6Z3kkJc9LoqxX/9D/U=; b=jOBm4GDILE3NSGqmwuGrQY5RgfLI245BgxSiNY0KYYtYs6OkLjlnNj4iXhZ2B9GgEk 8Euu8laLuBCAbymJtU0hBwZtv85RfP7a1TZL1YcGKX7N0lRzBPz2BApYy4YLx/u+sP/u ZDvS891fZftIj7V4VadSeuYLPFSsKFaewXWxCfYp5nSrmmPq4mvmPvfbUPeCrLLosPsw 9/DtIdHc4TbHKE3A3ekKMQ6Y9+5YE1CUmzr2UF3pcwQzms4CmRwaeq2gKtDqByLU9bWz 5rzLkNfl283x+mlIPmAKo2w8lCNZKUNsPO6JisVzwjbfGADQB+pKzJMdw+T3vyo0s5dx cQFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 145-v6si7953995pgd.509.2018.10.05.02.05.02; Fri, 05 Oct 2018 02:05:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728676AbeJEQCo (ORCPT + 99 others); Fri, 5 Oct 2018 12:02:44 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48510 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727823AbeJEQCo (ORCPT ); Fri, 5 Oct 2018 12:02:44 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E983180D; Fri, 5 Oct 2018 02:04:55 -0700 (PDT) Received: from [10.2.206.71] (e113077-lin.cambridge.arm.com [10.2.206.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD3E63F5B3; Fri, 5 Oct 2018 02:04:52 -0700 (PDT) Subject: Re: [PATCH v5 11/17] arm64: docs: document pointer authentication To: Kristina Martsenko , "linux-arm-kernel@lists.infradead.org" Cc: Adam Wallis , Amit Kachhap , Andrew Jones , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Christoffer Dall , Dave P Martin , Jacob Bramley , Kees Cook , Marc Zyngier , Mark Rutland , Suzuki Poulose , Will Deacon , "kvmarm@lists.cs.columbia.edu" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20181005084754.20950-1-kristina.martsenko@arm.com> <20181005084754.20950-12-kristina.martsenko@arm.com> From: Ramana Radhakrishnan Message-ID: <9acb0cd2-66b0-1c41-b1a8-7c70608e9a9b@foss.arm.com> Date: Fri, 5 Oct 2018 10:04:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181005084754.20950-12-kristina.martsenko@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/10/2018 09:47, Kristina Martsenko wrote: > From: Mark Rutland > > Now that we've added code to support pointer authentication, add some > documentation so that people can figure out if/how to use it. > > Signed-off-by: Mark Rutland > [kristina: update cpu-feature-registers.txt] > Signed-off-by: Kristina Martsenko > Cc: Andrew Jones > Cc: Catalin Marinas > Cc: Ramana Radhakrishnan > Cc: Will Deacon > --- > Documentation/arm64/booting.txt | 8 +++ > Documentation/arm64/cpu-feature-registers.txt | 4 ++ > Documentation/arm64/elf_hwcaps.txt | 5 ++ > Documentation/arm64/pointer-authentication.txt | 84 ++++++++++++++++++++++++++ > 4 files changed, 101 insertions(+) > create mode 100644 Documentation/arm64/pointer-authentication.txt > > diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt > index 8d0df62c3fe0..8df9f4658d6f 100644 > --- a/Documentation/arm64/booting.txt > +++ b/Documentation/arm64/booting.txt > @@ -205,6 +205,14 @@ Before jumping into the kernel, the following conditions must be met: > ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0. > - The DT or ACPI tables must describe a GICv2 interrupt controller. > > + For CPUs with pointer authentication functionality: > + - If EL3 is present: > + SCR_EL3.APK (bit 16) must be initialised to 0b1 > + SCR_EL3.API (bit 17) must be initialised to 0b1 > + - If the kernel is entered at EL1: > + HCR_EL2.APK (bit 40) must be initialised to 0b1 > + HCR_EL2.API (bit 41) must be initialised to 0b1 > + > The requirements described above for CPU mode, caches, MMUs, architected > timers, coherency and system registers apply to all CPUs. All CPUs must > enter the kernel in the same exception level. > diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt > index 7964f03846b1..b165677ffab9 100644 > --- a/Documentation/arm64/cpu-feature-registers.txt > +++ b/Documentation/arm64/cpu-feature-registers.txt > @@ -190,6 +190,10 @@ infrastructure: > |--------------------------------------------------| > | JSCVT | [15-12] | y | > |--------------------------------------------------| > + | API | [11-8] | y | > + |--------------------------------------------------| > + | APA | [7-4] | y | > + |--------------------------------------------------| > | DPB | [3-0] | y | > x--------------------------------------------------x > > diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt > index d6aff2c5e9e2..95509a7b0ffe 100644 > --- a/Documentation/arm64/elf_hwcaps.txt > +++ b/Documentation/arm64/elf_hwcaps.txt > @@ -178,3 +178,8 @@ HWCAP_ILRCPC > HWCAP_FLAGM > > Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001. > + > +HWCAP_APIA > + > + EL0 AddPac and Auth functionality using APIAKey_EL1 is enabled, as > + described by Documentation/arm64/pointer-authentication.txt. > diff --git a/Documentation/arm64/pointer-authentication.txt b/Documentation/arm64/pointer-authentication.txt > new file mode 100644 > index 000000000000..8a9cb5713770 > --- /dev/null > +++ b/Documentation/arm64/pointer-authentication.txt > @@ -0,0 +1,84 @@ > +Pointer authentication in AArch64 Linux > +======================================= > + > +Author: Mark Rutland > +Date: 2017-07-19 > + > +This document briefly describes the provision of pointer authentication > +functionality in AArch64 Linux. > + > + > +Architecture overview > +--------------------- > + > +The ARMv8.3 Pointer Authentication extension adds primitives that can be > +used to mitigate certain classes of attack where an attacker can corrupt > +the contents of some memory (e.g. the stack). > + > +The extension uses a Pointer Authentication Code (PAC) to determine > +whether pointers have been modified unexpectedly. A PAC is derived from > +a pointer, another value (such as the stack pointer), and a secret key > +held in system registers. > + > +The extension adds instructions to insert a valid PAC into a pointer, > +and to verify/remove the PAC from a pointer. The PAC occupies a number > +of high-order bits of the pointer, which varies dependent on the > +configured virtual address size and whether pointer tagging is in use. s/pointer tagging/top byte ignore unless that's the terminology in the rest of the kernel documentation ? > + > +A subset of these instructions have been allocated from the HINT > +encoding space. In the absence of the extension (or when disabled), > +these instructions behave as NOPs. Applications and libraries using > +these instructions operate correctly regardless of the presence of the > +extension. > + > + > +Basic support > +------------- > + > +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is > +present, the kernel will assign a random APIAKey value to each process > +at exec*() time. This key is shared by all threads within the process, > +and the key is preserved across fork(). Presence of functionality using > +APIAKey is advertised via HWCAP_APIA. > + > +Recent versions of GCC can compile code with APIAKey-based return > +address protection when passed the -msign-return-address option. This > +uses instructions in the HINT space, and such code can run on systems > +without the pointer authentication extension. Just a clarification. This uses instructions in the hint space for architecture levels less than armv8.3-a by default. If folks use -march=armv8.3-a you will start seeing the combined forms of retaa appear. > + > +The remaining instruction and data keys (APIBKey, APDAKey, APDBKey) are > +reserved for future use, and instructions using these keys must not be > +used by software until a purpose and scope for their use has been > +decided. To enable future software using these keys to function on > +contemporary kernels, where possible, instructions using these keys are > +made to behave as NOPs. > + > +The generic key (APGAKey) is currently unsupported. Instructions using > +the generic key must not be used by software. > + > + > +Debugging > +--------- > + > +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is > +present, the kernel will expose the position of TTBR0 PAC bits in the > +NT_ARM_PAC_MASK regset (struct user_pac_mask), which userspace can > +acqure via PTRACE_GETREGSET. > + > +Separate masks are exposed for data pointers and instruction pointers, > +as the set of PAC bits can vary between the two. Debuggers should not > +expect that HWCAP_APIA implies the presence (or non-presence) of this > +regset -- in future the kernel may support the use of APIBKey, APDAKey, > +and/or APBAKey, even in the absence of APIAKey. > + > +Note that the masks apply to TTBR0 addresses, and are not valid to apply > +to TTBR1 addresses (e.g. kernel pointers). > + > + > +Virtualization > +-------------- > + > +Pointer authentication is not currently supported in KVM guests. KVM > +will mask the feature bits from ID_AA64ISAR1_EL1, and attempted use of > +the feature will result in an UNDEFINED exception being injected into > +the guest. However applications using instructions from the hint space will continue to work albeit without any protection (as they would just be nops) ? regards, Ramana Reviewed-by: Ramana Radhakrishnan >