aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64/kernel
AgeCommit message (Collapse)AuthorFilesLines
2019-10-28arm64: entry: convert el1_sync to CMark Rutland3-71/+102
This patch converts the EL1 sync entry assembly logic to C code. Doing this will allow us to make changes in a slightly more readable way. A case in point is supporting kernel-first RAS. do_sea() should be called on the CPU that took the fault. Largely the assembly code is converted to C in a relatively straightforward manner. Since all sync sites share a common asm entry point, the ASM_BUG() instances are no longer required for effective backtraces back to assembly, and we don't need similar BUG() entries. The ESR_ELx.EC codes for all (supported) debug exceptions are now checked in the el1_sync_handler's switch statement, which renders the check in el1_dbg redundant. This both simplifies the el1_dbg handler, and makes the EL1 exception handling more robust to currently-unallocated ESR_ELx.EC encodings. Signed-off-by: Mark Rutland <[email protected]> [split out of a bigger series, added nokprobes, moved prototypes] Signed-off-by: James Morse <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Cc: Julien Thierry <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-28arm64: remove __exception annotationsJames Morse3-10/+7
Since commit 732674980139 ("arm64: unwind: reference pt_regs via embedded stack frame") arm64 has not used the __exception annotation to dump the pt_regs during stack tracing. in_exception_text() has no callers. This annotation is only used to blacklist kprobes, it means the same as __kprobes. Section annotations like this require the functions to be grouped together between the start/end markers, and placed according to the linker script. For kprobes we also have NOKPROBE_SYMBOL() which logs the symbol address in a section that kprobes parses and blacklists at boot. Using NOKPROBE_SYMBOL() instead lets kprobes publish the list of blacklisted symbols, and saves us from having an arm64 specific spelling of __kprobes. do_debug_exception() already has a NOKPROBE_SYMBOL() annotation. Signed-off-by: James Morse <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-28arm64: Silence clang warning on mismatched value/register sizesCatalin Marinas1-1/+1
Clang reports a warning on the __tlbi(aside1is, 0) macro expansion since the value size does not match the register size specified in the inline asm. Construct the ASID value using the __TLBI_VADDR() macro. Fixes: 222fc0c8503d ("arm64: compat: Workaround Neoverse-N1 #1542419 for compat user-space") Reported-by: Nathan Chancellor <[email protected]> Cc: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-25arm64: compat: Workaround Neoverse-N1 #1542419 for compat user-spaceJames Morse1-0/+11
Compat user-space is unable to perform ICIMVAU instructions from user-space. Instead it uses a compat-syscall. Add the workaround for Neoverse-N1 #1542419 to this code path. Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-25arm64: Fake the IminLine size on systems affected by Neoverse-N1 #1542419James Morse1-1/+7
Systems affected by Neoverse-N1 #1542419 support DIC so do not need to perform icache maintenance once new instructions are cleaned to the PoU. For the errata workaround, the kernel hides DIC from user-space, so that the unnecessary cache maintenance can be trapped by firmware. To reduce the number of traps, produce a fake IminLine value based on PAGE_SIZE. Signed-off-by: James Morse <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-25arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419James Morse2-1/+34
Cores affected by Neoverse-N1 #1542419 could execute a stale instruction when a branch is updated to point to freshly generated instructions. To workaround this issue we need user-space to issue unnecessary icache maintenance that we can trap. Start by hiding CTR_EL0.DIC. Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-25arm64: psci: Reduce the waiting time for cpu_psci_cpu_kill()Yunfeng Ye1-6/+9
In cases like suspend-to-disk and suspend-to-ram, a large number of CPU cores need to be shut down. At present, the CPU hotplug operation is serialised, and the CPU cores can only be shut down one by one. In this process, if PSCI affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill() needs to wait for 10ms. If hundreds of CPU cores need to be shut down, it will take a long time. Normally, there is no need to wait 10ms in cpu_psci_cpu_kill(). So change the wait interval from 10 ms to max 1 ms and use usleep_range() instead of msleep() for more accurate timer. In addition, reducing the time interval will increase the messages output, so remove the "Retry ..." message, instead, track time and output to the the sucessful message. Signed-off-by: Yunfeng Ye <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-25arm64: cpufeature: Fix typos in commentShaokun Zhang1-1/+1
Fix up one typos: CTR_E0 -> CTR_EL0 Cc: Will Deacon <[email protected]> Acked-by: Suzuki K Poulose <[email protected]> Signed-off-by: Shaokun Zhang <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-21arm64: Retrieve stolen time as paravirtualized guestSteven Price2-0/+143
Enable paravirtualization features when running under a hypervisor supporting the PV_TIME_ST hypercall. For each (v)CPU, we ask the hypervisor for the location of a shared page which the hypervisor will use to report stolen time to us. We set pv_time_ops to the stolen time function which simply reads the stolen value from the shared page for a VCPU. We guarantee single-copy atomicity using READ_ONCE which means we can also read the stolen time for another VCPU than the currently running one while it is potentially being updated by the hypervisor. Signed-off-by: Steven Price <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-10-21arm/arm64: Make use of the SMCCC 1.1 wrapperSteven Price1-52/+29
Rather than directly choosing which function to use based on psci_ops.conduit, use the new arm_smccc_1_1 wrapper instead. In some cases we still need to do some operations based on the conduit, but the code duplication is removed. No functional change. Signed-off-by: Steven Price <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-10-18arm64: Add ARM64_WORKAROUND_1319367 for all A57 and A72 versionsMarc Zyngier1-3/+10
Rework the EL2 vector hardening that is only selected for A57 and A72 so that the table can also be used for ARM64_WORKAROUND_1319367. Acked-by: Catalin Marinas <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-10-18arm64: Use pr_warn instead of pr_warningKefeng Wang2-10/+9
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent <prefix>_warn style. Let's do it. Link: http://lkml.kernel.org/r/[email protected] To: [email protected] Cc: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Petr Mladek <[email protected]>
2019-10-17Merge branch 'errata/tx2-219' into for-next/fixesWill Deacon2-0/+40
Workaround for Cavium/Marvell ThunderX2 erratum #219. * errata/tx2-219: arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected arm64: Avoid Cavium TX2 erratum 219 when switching TTBR arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
2019-10-16arm64: tags: Preserve tags for addresses translated via TTBR1Will Deacon1-2/+2
Sign-extending TTBR1 addresses when converting to an untagged address breaks the documented POSIX semantics for mlock() in some obscure error cases where we end up returning -EINVAL instead of -ENOMEM as a direct result of rewriting the upper address bits. Rework the untagged_addr() macro to preserve the upper address bits for TTBR1 addresses and only clear the tag bits for user addresses. This matches the behaviour of the 'clear_address_tag' assembly macro, so rename that and align the implementations at the same time so that they use the same instruction sequences for the tag manipulation. Link: https://lore.kernel.org/stable/[email protected]/ Reported-by: Jan Stancek <[email protected]> Tested-by: Jan Stancek <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Tested-by: Catalin Marinas <[email protected]> Reviewed-by: Vincenzo Frascino <[email protected]> Tested-by: Vincenzo Frascino <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-16arm64: entry.S: Do not preempt from IRQ before all cpufeatures are enabledJulien Thierry2-1/+19
Preempting from IRQ-return means that the task has its PSTATE saved on the stack, which will get restored when the task is resumed and does the actual IRQ return. However, enabling some CPU features requires modifying the PSTATE. This means that, if a task was scheduled out during an IRQ-return before all CPU features are enabled, the task might restore a PSTATE that does not include the feature enablement changes once scheduled back in. * Task 1: PAN == 0 ---| |--------------- | |<- return from IRQ, PSTATE.PAN = 0 | <- IRQ | +--------+ <- preempt() +-- ^ | reschedule Task 1, PSTATE.PAN == 1 * Init: --------------------+------------------------ ^ | enable_cpu_features set PSTATE.PAN on all CPUs Worse than this, since PSTATE is untouched when task switching is done, a task missing the new bits in PSTATE might affect another task, if both do direct calls to schedule() (outside of IRQ/exception contexts). Fix this by preventing preemption on IRQ-return until features are enabled on all CPUs. This way the only PSTATE values that are saved on the stack are from synchronous exceptions. These are expected to be fatal this early, the exception is BRK for WARN_ON(), but as this uses do_debug_exception() which keeps IRQs masked, it shouldn't call schedule(). Signed-off-by: Julien Thierry <[email protected]> [james: Replaced a really cool hack, with an even simpler static key in C. expanded commit message with Julien's cover-letter ascii art] Signed-off-by: James Morse <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-15arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clearMarc Zyngier1-2/+4
The GICv3 architecture specification is incredibly misleading when it comes to PMR and the requirement for a DSB. It turns out that this DSB is only required if the CPU interface sends an Upstream Control message to the redistributor in order to update the RD's view of PMR. This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't the case in Linux. It can still be set from EL3, so some special care is required. But the upshot is that in the (hopefuly large) majority of the cases, we can drop the DSB altogether. This relies on a new static key being set if the boot CPU has PMHE set. The drawback is that this static key has to be exported to modules. Cc: Will Deacon <[email protected]> Cc: James Morse <[email protected]> Cc: Julien Thierry <[email protected]> Cc: Suzuki K Poulose <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-14arm64: hibernate: check pgd table allocationPavel Tatashin1-1/+8
There is a bug in create_safe_exec_page(), when page table is allocated it is not checked that table is allocated successfully: But it is dereferenced in: pgd_none(READ_ONCE(*pgdp)). Check that allocation was successful. Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk") Reviewed-by: James Morse <[email protected]> Signed-off-by: Pavel Tatashin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-14arm64: cpufeature: Treat ID_AA64ZFR0_EL1 as RAZ when SVE is not enabledJulien Grall1-5/+10
If CONFIG_ARM64_SVE=n then we fail to report ID_AA64ZFR0_EL1 as 0 when read by userspace, despite being required by the architecture. Although this is theoretically a change in ABI, userspace will first check for the presence of SVE via the HWCAP or the ID_AA64PFR0_EL1.SVE field before probing the ID_AA64ZFR0_EL1 register. Given that these are reported correctly for this configuration, we can safely tighten up the current behaviour. Ensure ID_AA64ZFR0_EL1 is treated as RAZ when CONFIG_ARM64_SVE=n. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Dave Martin <[email protected]> Fixes: 06a916feca2b ("arm64: Expose SVE2 features for userspace") Signed-off-by: Will Deacon <[email protected]>
2019-10-14firmware: arm_sdei: use common SMCCC_CONDUIT_*Mark Rutland1-1/+2
Now that we have common definitions for SMCCC conduits, move the SDEI code over to them, and remove the SDEI-specific definitions. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Acked-by: James Morse <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-14arm64: errata: use arm_smccc_1_1_get_conduit()Mark Rutland1-25/+12
Now that we have arm_smccc_1_1_get_conduit(), we can hide the PSCI implementation details from the arm64 cpu errata code, so let's do so. As arm_smccc_1_1_get_conduit() implicitly checks that the SMCCC version is at least SMCCC_VERSION_1_1, we no longer need to check this explicitly where switch statements have a default case, e.g. in has_ssbd_mitigation(). There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Will Deacon <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2019-10-10seccomp: simplify secure_computing()Christian Brauner1-1/+1
Afaict, the struct seccomp_data argument to secure_computing() is unused by all current callers. So let's remove it. The argument was added in [1]. It was added because having the arch supply the syscall arguments used to be faster than having it done by secure_computing() (cf. Andy's comment in [2]). This is not true anymore though. /* References */ [1]: 2f275de5d1ed ("seccomp: Add a seccomp_data parameter secure_computing()") [2]: https://lore.kernel.org/r/CALCETrU_fs_At-hTpr231kpaAd0z7xJN4ku-DvzhRU6cvcJA_w@mail.gmail.com Signed-off-by: Christian Brauner <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Drewry <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Borislav Petkov <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2019-10-08arm64: armv8_deprecated: Checking return value for memory allocationYunfeng Ye1-0/+5
There are no return value checking when using kzalloc() and kcalloc() for memory allocation. so add it. Signed-off-by: Yunfeng Ye <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-08arm64: Avoid Cavium TX2 erratum 219 when switching TTBRMarc Zyngier2-0/+7
As a PRFM instruction racing against a TTBR update can have undesirable effects on TX2, NOP-out such PRFM on cores that are affected by the TX2-219 erratum. Cc: <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-08arm64: Enable workaround for Cavium TX2 erratum 219 when running SMTMarc Zyngier1-0/+33
It appears that the only case where we need to apply the TX2_219_TVM mitigation is when the core is in SMT mode. So let's condition the enabling on detecting a CPU whose MPIDR_EL1.Aff0 is non-zero. Cc: <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Rename COMPATCC to CC_COMPATWill Deacon1-13/+13
For consistency with CROSS_COMPILE_COMPAT, mechanically rename COMPATCC to CC_COMPAT so that specifying aspects of the compat vDSO toolchain in the environment isn't needlessly confusing. Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Pass '--target' option to clang via VDSO_CAFLAGSWill Deacon1-1/+5
Directly passing the '--target' option to clang by appending to COMPATCC does not work if COMPATCC has been specified explicitly as an argument to Make unless the 'override' directive is used, which is ugly and different to what is done in the top-level Makefile. Move the '--target' option for clang out of COMPATCC and into VDSO_CAFLAGS, where it will be picked up when compiling and assembling the 32-bit vDSO under clang. Reported-by: Catalin Marinas <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionallyWill Deacon1-4/+2
KBUILD_CPPFLAGS is defined differently depending on whether the main compiler is clang or not. This means that it is not possible to build the compat vDSO with GCC if the rest of the kernel is built with clang. Define VDSO_CPPFLAGS directly to break this dependency and allow a clang kernel to build a compat vDSO with GCC: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- CC=clang \ COMPATCC=arm-linux-gnueabihf-gcc Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Move definition of COMPATCC into vdso32/MakefileWill Deacon1-0/+6
There's no need to export COMPATCC, so just define it locally in the vdso32/Makefile, which is the only place where it is used. Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Remove jump label config option in MakefileVincenzo Frascino1-3/+0
The jump labels are not used in vdso32 since it is not possible to run runtime patching on them. Remove the configuration option from the Makefile. Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Acked-by: Catalin Marinas <[email protected]> Tested-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Detect binutils support for dmb ishldVincenzo Frascino1-0/+9
Older versions of binutils (prior to 2.24) do not support the "ISHLD" option for memory barrier instructions, which leads to a build failure when assembling the vdso32 library. Add a compilation time mechanism that detects if binutils supports those instructions and configure the kernel accordingly. Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Reported-by: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Tested-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso: Remove stale files from old assembly implementationVincenzo Frascino1-0/+0
Moving over to the generic C implementation of the vDSO inadvertently left some stale files behind which are no longer used. Remove them. Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Acked-by: Catalin Marinas <[email protected]> Tested-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-07arm64: vdso32: Fix broken compat vDSO build warningsVincenzo Frascino1-2/+0
The .config file and the generated include/config/auto.conf can end up out of sync after a set of commands since CONFIG_CROSS_COMPILE_COMPAT_VDSO is not updated correctly. The sequence can be reproduced as follows: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig [...] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Which results in: arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built even though the compat vDSO has been built: $ file arch/arm64/kernel/vdso32/vdso.so arch/arm64/kernel/vdso32/vdso.so: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c67f6c786f2d2d6f86c71f708595594aa25247f6, stripped A similar case that involves changing the configuration parameter multiple times can be reconducted to the same family of problems. Remove the use of CONFIG_CROSS_COMPILE_COMPAT_VDSO altogether and instead rely on the cross-compiler prefix coming from the environment via CROSS_COMPILE_COMPAT, much like we do for the rest of the kernel. Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Reported-by: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-04arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419James Morse1-3/+9
CPUs affected by Neoverse-N1 #1542419 may execute a stale instruction if it was recently modified. The affected sequence requires freshly written instructions to be executable before a branch to them is updated. There are very few places in the kernel that modify executable text, all but one come with sufficient synchronisation: * The module loader's flush_module_icache() calls flush_icache_range(), which does a kick_all_cpus_sync() * bpf_int_jit_compile() calls flush_icache_range(). * Kprobes calls aarch64_insn_patch_text(), which does its work in stop_machine(). * static keys and ftrace both patch between nops and branches to existing kernel code (not generated code). The affected sequence is the interaction between ftrace and modules. The module PLT is cleaned using __flush_icache_range() as the trampoline shouldn't be executable until we update the branch to it. Drop the double-underscore so that this path runs kick_all_cpus_sync() too. Signed-off-by: James Morse <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-04arm64: Fix incorrect irqflag restore for priority masking for compatJames Morse1-0/+1
Commit bd82d4bd2188 ("arm64: Fix incorrect irqflag restore for priority masking") added a macro to the entry.S call paths that leave the PSTATE.I bit set. This tells the pPNMI masking logic that interrupts are masked by the CPU, not by the PMR. This value is read back by local_daif_save(). Commit bd82d4bd2188 added this call to el0_svc, as el0_svc_handler is called with interrupts masked. el0_svc_compat was missed, but should be covered in the same way as both of these paths end up in el0_svc_common(), which expects to unmask interrupts. Fixes: bd82d4bd2188 ("arm64: Fix incorrect irqflag restore for priority masking") Signed-off-by: James Morse <[email protected]> Cc: Julien Thierry <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-04arm64: cpufeature: Effectively expose FRINT capability to userspaceJulien Grall1-0/+1
The HWCAP framework will detect a new capability based on the sanitized version of the ID registers. Sanitization is based on a whitelist, so any field not described will end up to be zeroed. At the moment, ID_AA64ISAR1_EL1.FRINTTS is not described in ftr_id_aa64isar1. This means the field will be zeroed and therefore the userspace will not be able to see the HWCAP even if the hardware supports the feature. This can be fixed by describing the field in ftr_id_aa64isar1. Fixes: ca9503fc9e98 ("arm64: Expose FRINT capabilities to userspace") Signed-off-by: Julien Grall <[email protected]> Cc: [email protected] Signed-off-by: Will Deacon <[email protected]>
2019-10-01arm64/sve: Fix wrong free for task->thread.sve_stateMasayoshi Mizuma1-17/+15
The system which has SVE feature crashed because of the memory pointed by task->thread.sve_state was destroyed by someone. That is because sve_state is freed while the forking the child process. The child process has the pointer of sve_state which is same as the parent's because the child's task_struct is copied from the parent's one. If the copy_process() fails as an error on somewhere, for example, copy_creds(), then the sve_state is freed even if the parent is alive. The flow is as follows. copy_process p = dup_task_struct => arch_dup_task_struct *dst = *src; // copy the entire region. : retval = copy_creds if (retval < 0) goto bad_fork_free; : bad_fork_free: ... delayed_free_task(p); => free_task => arch_release_task_struct => fpsimd_release_task => __sve_free => kfree(task->thread.sve_state); // free the parent's sve_state Move child's sve_state = NULL and clearing TIF_SVE flag to arch_dup_task_struct() so that the child doesn't free the parent's one. There is no need to wait until copy_process() to clear TIF_SVE for dst, because the thread flags for dst are initialized already by copying the src task_struct. This change simplifies the code, so get rid of comments that are no longer needed. As a note, arm64 used to have thread_info on the stack. So it would not be possible to clear TIF_SVE until the stack is initialized. From commit c02433dd6de3 ("arm64: split thread_info from task stack"), the thread_info is part of the task, so it should be valid to modify the flag from arch_dup_task_struct(). Cc: [email protected] # 4.15.x- Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Signed-off-by: Masayoshi Mizuma <[email protected]> Reported-by: Hidetoshi Seto <[email protected]> Suggested-by: Dave Martin <[email protected]> Reviewed-by: Dave Martin <[email protected]> Tested-by: Julien Grall <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-01arm64: errata: Update stale commentThierry Reding1-2/+2
Commit 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof") renamed the caller of the install_bp_hardening_cb() function but forgot to update a comment, which can be confusing when trying to follow the code flow. Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-09-24arm64, mm: make randomization selected by generic topdown mmap layoutAlexandre Ghiti1-8/+0
This commits selects ARCH_HAS_ELF_RANDOMIZE when an arch uses the generic topdown mmap layout functions so that this security feature is on by default. Note that this commit also removes the possibility for arm64 to have elf randomization and no MMU: without MMU, the security added by randomization is worth nothing. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Alexandre Ghiti <[email protected]> Acked-by: Catalin Marinas <[email protected]> Acked-by: Kees Cook <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Luis Chamberlain <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: James Hogan <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Burton <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Russell King <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-09-16Merge tag 'arm64-upstream' of ↵Linus Torvalds24-408/+399
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Will Deacon: "Although there isn't tonnes of code in terms of line count, there are a fair few headline features which I've noted both in the tag and also in the merge commits when I pulled everything together. The part I'm most pleased with is that we had 35 contributors this time around, which feels like a big jump from the usual small group of core arm64 arch developers. Hopefully they all enjoyed it so much that they'll continue to contribute, but we'll see. It's probably worth highlighting that we've pulled in a branch from the risc-v folks which moves our CPU topology code out to where it can be shared with others. Summary: - 52-bit virtual addressing in the kernel - New ABI to allow tagged user pointers to be dereferenced by syscalls - Early RNG seeding by the bootloader - Improve robustness of SMP boot - Fix TLB invalidation in light of recent architectural clarifications - Support for i.MX8 DDR PMU - Remove direct LSE instruction patching in favour of static keys - Function error injection using kprobes - Support for the PPTT "thread" flag introduced by ACPI 6.3 - Move PSCI idle code into proper cpuidle driver - Relaxation of implicit I/O memory barriers - Build with RELR relocations when toolchain supports them - Numerous cleanups and non-critical fixes" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (114 commits) arm64: remove __iounmap arm64: atomics: Use K constraint when toolchain appears to support it arm64: atomics: Undefine internal macros after use arm64: lse: Make ARM64_LSE_ATOMICS depend on JUMP_LABEL arm64: asm: Kill 'asm/atomic_arch.h' arm64: lse: Remove unused 'alt_lse' assembly macro arm64: atomics: Remove atomic_ll_sc compilation unit arm64: avoid using hard-coded registers for LSE atomics arm64: atomics: avoid out-of-line ll/sc atomics arm64: Use correct ll/sc atomic constraints jump_label: Don't warn on __exit jump entries docs/perf: Add documentation for the i.MX8 DDR PMU perf/imx_ddr: Add support for AXI ID filtering arm64: kpti: ensure patched kernel text is fetched from PoU arm64: fix fixmap copy for 16K pages and 48-bit VA perf/smmuv3: Validate groups for global filtering perf/smmuv3: Validate group size arm64: Relax Documentation/arm64/tagged-pointers.rst arm64: kvm: Replace hardcoded '1' with SYS_PAR_EL1_F arm64: mm: Ignore spurious translation faults taken from the kernel ...
2019-08-30Merge branches 'for-next/52-bit-kva', 'for-next/cpu-topology', ↵Will Deacon12-329/+204
'for-next/error-injection', 'for-next/perf', 'for-next/psci-cpuidle', 'for-next/rng', 'for-next/smpboot', 'for-next/tbi' and 'for-next/tlbi' into for-next/core * for-next/52-bit-kva: (25 commits) Support for 52-bit virtual addressing in kernel space * for-next/cpu-topology: (9 commits) Move CPU topology parsing into core code and add support for ACPI 6.3 * for-next/error-injection: (2 commits) Support for function error injection via kprobes * for-next/perf: (8 commits) Support for i.MX8 DDR PMU and proper SMMUv3 group validation * for-next/psci-cpuidle: (7 commits) Move PSCI idle code into a new CPUidle driver * for-next/rng: (4 commits) Support for 'rng-seed' property being passed in the devicetree * for-next/smpboot: (3 commits) Reduce fragility of secondary CPU bringup in debug configurations * for-next/tbi: (10 commits) Introduce new syscall ABI with relaxed requirements for pointer tags * for-next/tlbi: (6 commits) Handle spurious page faults arising from kernel space
2019-08-27arm64: smp: Treat unknown boot failures as being 'stuck in kernel'Will Deacon1-0/+1
When we fail to bring a secondary CPU online and it fails in an unknown state, we should assume the worst and increment 'cpus_stuck_in_kernel' so that things like kexec() are disabled. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-27arm64: smp: Don't enter kernel with NULL stack pointer or task structWill Deacon2-0/+9
Although SMP bringup is inherently racy, we can significantly reduce the window during which secondary CPUs can unexpectedly enter the kernel by sanity checking the 'stack' and 'task' fields of the 'secondary_data' structure. If the booting CPU gave up waiting for us, then they will have been cleared to NULL and we should spin in a WFE; WFI loop instead. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-27arm64: smp: Increase secondary CPU boot timeout valueWill Deacon1-1/+1
When many debug options are enabled simultaneously (e.g. PROVE_LOCKING, KMEMLEAK, DEBUG_PAGE_ALLOC, KASAN etc), it is possible for us to timeout when attempting to boot a secondary CPU and give up. Unfortunately, the CPU will /eventually/ appear, and sit in the background happily stuck in a recursive exception due to a NULL stack pointer. Increase the timeout to 5s, which will of course be enough for anybody. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-23arm64: kexec_file: add rng-seed supportHsin-Yi Wang1-1/+17
Adding "rng-seed" to dtb. It's fine to add this property if original fdt doesn't contain it. Since original seed will be wiped after read, so use a default size 128 bytes here. Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-23arm64: map FDT as RW for early_init_dt_scan()Hsin-Yi Wang2-5/+9
Currently in arm64, FDT is mapped to RO before it's passed to early_init_dt_scan(). However, there might be some codes (eg. commit "fdt: add support for rng-seed") that need to modify FDT during init. Map FDT to RO after early fixups are done. Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Mike Rapoport <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-21arm64: entry: Move ct_user_exit before any other exceptionJames Morse2-17/+28
When taking an SError or Debug exception from EL0, we run the C handler for these exceptions before updating the context tracking code and unmasking lower priority interrupts. When booting with nohz_full lockdep tells us we got this wrong: | ============================= | WARNING: suspicious RCU usage | 5.3.0-rc2-00010-gb4b5e9dcb11b-dirty #11271 Not tainted | ----------------------------- | include/linux/rcupdate.h:643 rcu_read_unlock() used illegally wh! | | other info that might help us debug this: | | | RCU used illegally from idle CPU! | rcu_scheduler_active = 2, debug_locks = 1 | RCU used illegally from extended quiescent state! | 1 lock held by a.out/432: | #0: 00000000c7a79515 (rcu_read_lock){....}, at: brk_handler+0x00 | | stack backtrace: | CPU: 1 PID: 432 Comm: a.out Not tainted 5.3.0-rc2-00010-gb4b5e9d1 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno De8 | Call trace: | dump_backtrace+0x0/0x140 | show_stack+0x14/0x20 | dump_stack+0xbc/0x104 | lockdep_rcu_suspicious+0xf8/0x108 | brk_handler+0x164/0x1b0 | do_debug_exception+0x11c/0x278 | el0_dbg+0x14/0x20 Moving the ct_user_exit calls to be before do_debug_exception() means they are also before trace_hardirqs_off() has been updated. Add a new ct_user_exit_irqoff macro to avoid the context-tracking code using irqsave/restore before we've updated trace_hardirqs_off(). To be consistent, do this everywhere. The C helper is called enter_from_user_mode() to match x86 in the hope we can merge them into kernel/context_tracking.c later. Cc: Masami Hiramatsu <[email protected]> Fixes: 6c81fe7925cc4c42 ("arm64: enable context tracking") Signed-off-by: James Morse <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-20arm64: Change the tagged_addr sysctl control semantics to only prevent the ↵Catalin Marinas1-7/+10
opt-in First rename the sysctl control to abi.tagged_addr_disabled and make it default off (zero). When abi.tagged_addr_disabled == 1, only block the enabling of the TBI ABI via prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE). Getting the status of the ABI or disabling it is still allowed. Acked-by: Andrey Konovalov <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-20arm64: perf_event: Add missing header needed for smp_processor_id()Raphael Gault1-0/+1
In perf_event.c we use smp_processor_id(), but we haven't included <linux/smp.h> where it is defined, and rely on this being pulled in via a transitive include. Let's make this more robust by including <linux.smp.h> explicitly. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Raphael Gault <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-08-16Merge tag 'arm64-fixes' of ↵Linus Torvalds2-12/+24
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Don't taint the kernel if CPUs have different sets of page sizes supported (other than the one in use). - Issue I-cache maintenance for module ftrace trampoline. * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: ftrace: Ensure module ftrace trampoline is coherent with I-side arm64: cpufeature: Don't treat granule sizes as strict
2019-08-16arm64: ftrace: Ensure module ftrace trampoline is coherent with I-sideWill Deacon1-9/+13
The initial support for dynamic ftrace trampolines in modules made use of an indirect branch which loaded its target from the beginning of a special section (e71a4e1bebaf7 ("arm64: ftrace: add support for far branches to dynamic ftrace")). Since no instructions were being patched, no cache maintenance was needed. However, later in be0f272bfc83 ("arm64: ftrace: emit ftrace-mod.o contents through code") this code was reworked to output the trampoline instructions directly into the PLT entry but, unfortunately, the necessary cache maintenance was overlooked. Add a call to __flush_icache_range() after writing the new trampoline instructions but before patching in the branch to the trampoline. Cc: Ard Biesheuvel <[email protected]> Cc: James Morse <[email protected]> Cc: <[email protected]> Fixes: be0f272bfc83 ("arm64: ftrace: emit ftrace-mod.o contents through code") Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>