mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 03:27:44 -04:00
arm64 festive updates for 4.21
In the end, we ended up with quite a lot more than I expected: - Support for ARMv8.3 Pointer Authentication in userspace (CRIU and kernel-side support to come later) - Support for per-thread stack canaries, pending an update to GCC that is currently undergoing review - Support for kexec_file_load(), which permits secure boot of a kexec payload but also happens to improve the performance of kexec dramatically because we can avoid the sucky purgatory code from userspace. Kdump will come later (requires updates to libfdt). - Optimisation of our dynamic CPU feature framework, so that all detected features are enabled via a single stop_machine() invocation - KPTI whitelisting of Cortex-A CPUs unaffected by Meltdown, so that they can benefit from global TLB entries when KASLR is not in use - 52-bit virtual addressing for userspace (kernel remains 48-bit) - Patch in LSE atomics for per-cpu atomic operations - Custom preempt.h implementation to avoid unconditional calls to preempt_schedule() from preempt_enable() - Support for the new 'SB' Speculation Barrier instruction - Vectorised implementation of XOR checksumming and CRC32 optimisations - Workaround for Cortex-A76 erratum #1165522 - Improved compatibility with Clang/LLD - Support for TX2 system PMUS for profiling the L3 cache and DMC - Reflect read-only permissions in the linear map by default - Ensure MMIO reads are ordered with subsequent calls to Xdelay() - Initial support for memory hotplug - Tweak the threshold when we invalidate the TLB by-ASID, so that mremap() performance is improved for ranges spanning multiple PMDs. - Minor refactoring and cleanups -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABCgAGBQJcE4TmAAoJELescNyEwWM0Nr0H/iaU7/wQSzHyNXtZoImyKTul Blu2ga4/EqUrTU7AVVfmkl/3NBILWlgQVpY6tH6EfXQuvnxqD7CizbHyLdyO+z0S B5PsFUH2GLMNAi48AUNqGqkgb2knFbg+T+9IimijDBkKg1G/KhQnRg6bXX32mLJv Une8oshUPBVJMsHN1AcQknzKariuoE3u0SgJ+eOZ9yA2ZwKxP4yy1SkDt3xQrtI0 lojeRjxcyjTP1oGRNZC+BWUtGOT35p7y6cGTnBd/4TlqBGz5wVAJUcdoxnZ6JYVR O8+ob9zU+4I0+SKt80s7pTLqQiL9rxkKZ5joWK1pr1g9e0s5N5yoETXKFHgJYP8= =sYdt -----END PGP SIGNATURE----- Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 festive updates from Will Deacon: "In the end, we ended up with quite a lot more than I expected: - Support for ARMv8.3 Pointer Authentication in userspace (CRIU and kernel-side support to come later) - Support for per-thread stack canaries, pending an update to GCC that is currently undergoing review - Support for kexec_file_load(), which permits secure boot of a kexec payload but also happens to improve the performance of kexec dramatically because we can avoid the sucky purgatory code from userspace. Kdump will come later (requires updates to libfdt). - Optimisation of our dynamic CPU feature framework, so that all detected features are enabled via a single stop_machine() invocation - KPTI whitelisting of Cortex-A CPUs unaffected by Meltdown, so that they can benefit from global TLB entries when KASLR is not in use - 52-bit virtual addressing for userspace (kernel remains 48-bit) - Patch in LSE atomics for per-cpu atomic operations - Custom preempt.h implementation to avoid unconditional calls to preempt_schedule() from preempt_enable() - Support for the new 'SB' Speculation Barrier instruction - Vectorised implementation of XOR checksumming and CRC32 optimisations - Workaround for Cortex-A76 erratum #1165522 - Improved compatibility with Clang/LLD - Support for TX2 system PMUS for profiling the L3 cache and DMC - Reflect read-only permissions in the linear map by default - Ensure MMIO reads are ordered with subsequent calls to Xdelay() - Initial support for memory hotplug - Tweak the threshold when we invalidate the TLB by-ASID, so that mremap() performance is improved for ranges spanning multiple PMDs. - Minor refactoring and cleanups" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (125 commits) arm64: kaslr: print PHYS_OFFSET in dump_kernel_offset() arm64: sysreg: Use _BITUL() when defining register bits arm64: cpufeature: Rework ptr auth hwcaps using multi_entry_cap_matches arm64: cpufeature: Reduce number of pointer auth CPU caps from 6 to 4 arm64: docs: document pointer authentication arm64: ptr auth: Move per-thread keys from thread_info to thread_struct arm64: enable pointer authentication arm64: add prctl control for resetting ptrauth keys arm64: perf: strip PAC when unwinding userspace arm64: expose user PAC bit positions via ptrace arm64: add basic pointer authentication support arm64/cpufeature: detect pointer authentication arm64: Don't trap host pointer auth use to EL2 arm64/kvm: hide ptrauth from guests arm64/kvm: consistently handle host HCR_EL2 flags arm64: add pointer authentication register bits arm64: add comments about EC exception levels arm64: perf: Treat EXCLUDE_EL* bit definitions as unsigned arm64: kpti: Whitelist Cortex-A CPUs that don't implement the CSV3 field arm64: enable per-task stack canaries ...
This commit is contained in:
commit
5694cecdb0
138 changed files with 4287 additions and 1197 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -184,12 +184,20 @@ infrastructure:
|
|||
x--------------------------------------------------x
|
||||
| Name | bits | visible |
|
||||
|--------------------------------------------------|
|
||||
| GPI | [31-28] | y |
|
||||
|--------------------------------------------------|
|
||||
| GPA | [27-24] | y |
|
||||
|--------------------------------------------------|
|
||||
| LRCPC | [23-20] | y |
|
||||
|--------------------------------------------------|
|
||||
| FCMA | [19-16] | y |
|
||||
|--------------------------------------------------|
|
||||
| JSCVT | [15-12] | y |
|
||||
|--------------------------------------------------|
|
||||
| API | [11-8] | y |
|
||||
|--------------------------------------------------|
|
||||
| APA | [7-4] | y |
|
||||
|--------------------------------------------------|
|
||||
| DPB | [3-0] | y |
|
||||
x--------------------------------------------------x
|
||||
|
||||
|
|
|
|||
|
|
@ -182,3 +182,15 @@ HWCAP_FLAGM
|
|||
HWCAP_SSBS
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
|
||||
|
||||
HWCAP_PACA
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
|
||||
ID_AA64ISAR1_EL1.API == 0b0001, as described by
|
||||
Documentation/arm64/pointer-authentication.txt.
|
||||
|
||||
HWCAP_PACG
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
|
||||
ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
|
||||
Documentation/arm64/pointer-authentication.txt.
|
||||
|
|
|
|||
88
Documentation/arm64/pointer-authentication.txt
Normal file
88
Documentation/arm64/pointer-authentication.txt
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
Pointer authentication in AArch64 Linux
|
||||
=======================================
|
||||
|
||||
Author: Mark Rutland <[email protected]>
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The extension provides five separate keys to generate PACs - two for
|
||||
instruction addresses (APIAKey, APIBKey), two for data addresses
|
||||
(APDAKey, APDBKey), and one for generic authentication (APGAKey).
|
||||
|
||||
|
||||
Basic support
|
||||
-------------
|
||||
|
||||
When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is
|
||||
present, the kernel will assign random key values to each process at
|
||||
exec*() time. The keys are shared by all threads within the process, and
|
||||
are preserved across fork().
|
||||
|
||||
Presence of address authentication functionality is advertised via
|
||||
HWCAP_PACA, and generic authentication functionality via HWCAP_PACG.
|
||||
|
||||
The number of bits that the PAC occupies in a pointer is 55 minus the
|
||||
virtual address size configured by the kernel. For example, with a
|
||||
virtual address size of 48, the PAC is 7 bits wide.
|
||||
|
||||
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 (unless -march=armv8.3-a or higher
|
||||
is also passed), and such code can run on systems without the pointer
|
||||
authentication extension.
|
||||
|
||||
In addition to exec(), keys can also be reinitialized to random values
|
||||
using the PR_PAC_RESET_KEYS prctl. A bitmask of PR_PAC_APIAKEY,
|
||||
PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY and PR_PAC_APGAKEY
|
||||
specifies which keys are to be reinitialized; specifying 0 means "all
|
||||
keys".
|
||||
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
||||
When CONFIG_ARM64_PTR_AUTH is selected, and HW support for address
|
||||
authentication 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 acquire via PTRACE_GETREGSET.
|
||||
|
||||
The regset is exposed only when HWCAP_PACA is set. Separate masks are
|
||||
exposed for data pointers and instruction pointers, as the set of PAC
|
||||
bits can vary between the two. 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.
|
||||
|
|
@ -57,6 +57,7 @@ stable kernels.
|
|||
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
|
||||
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
|
||||
| ARM | Cortex-A76 | #1188873 | ARM64_ERRATUM_1188873 |
|
||||
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
|
||||
| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
|
||||
| ARM | MMU-500 | #841119,#826419 | N/A |
|
||||
| | | | |
|
||||
|
|
|
|||
Loading…
Reference in a new issue