- 12 Nov, 2019 40 commits
-
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit afaf6838 upstream. Introduce C and asm helpers to sanitize user address, taking the address range they target into account. Use asm helper for existing sanitization in __copy_from_user(). Signed-off-by:
Julien Thierry <julien.thierry@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David A. Long <dave.long@linaro.org> Reviewed-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit e3aa6243 upstream. When Spectre mitigation is required, __put_user() needs to include check_uaccess. This is already the case for put_user(), so just make __put_user() an alias of put_user(). Signed-off-by:
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 621afc67 upstream. A mispredicted conditional call to set_fs could result in the wrong addr_limit being forwarded under speculation to a subsequent access_ok check, potentially forming part of a spectre-v1 attack using uaccess routines. This patch prevents this forwarding from taking place, but putting heavy barriers in set_fs after writing the addr_limit. Porting commit c2f0ad4f ("arm64: uaccess: Prevent speculative use of the current addr_limit"). Signed-off-by:
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 18ea66bd upstream. With Spectre-v1.1 mitigations, __put_user_error is pointless. In an attempt to remove it, replace its references in frame setups with __put_user. Signed-off-by:
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 31950890 upstream. Copy events to user using __copy_to_user() rather than copy members of individually with __put_user_error(). This has the benefit of disabling/enabling PAN once per event intead of once per event member. Signed-off-by:
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 3aa2df6e upstream. Use __copy_to_user() rather than __put_user_error() for individual members when saving VFP state. This has the benefit of disabling/enabling PAN once per copied struct intead of once per write. Signed-off-by:
-
Julien Thierry authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 5ca451cf upstream. When saving the ARM integer registers, use __copy_to_user() to copy them into user signal frame, rather than __put_user_error(). This has the benefit of disabling/enabling PAN once for the whole copy intead of once per write. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit a3c0f847 upstream. Spectre variant 1 attacks are about this sequence of pseudo-code: index = load(user-manipulated pointer); access(base + index * stride); In order for the cache side-channel to work, the access() must me made to memory which userspace can detect whether cache lines have been loaded. On 32-bit ARM, this must be either user accessible memory, or a kernel mapping of that same user accessible memory. The problem occurs when the load() speculatively loads privileged data, and the subsequent access() is made to user accessible memory. Any load() which makes use of a user-maniplated pointer is a potential problem if the data it has loaded is used in a subsequent access. This also applies for the access() if the data loaded by that access is used by a subsequent access. Harden the get_user() accessors against Spectre attacks by forcing out of bounds addresses to a NULL pointer. This prevents get_user() being used as the load() step above. As a side effect, put_user() will also be affected even though it isn't implicated. Also harden copy_from_user() by redoing the bounds check within the arm_copy_from_user() code, and NULLing the pointer if out of bounds. Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit b1cd0a14 upstream. Fixing __get_user() for spectre variant 1 is not sane: we would have to add address space bounds checking in order to validate that the location should be accessed, and then zero the address if found to be invalid. Since __get_user() is supposed to avoid the bounds check, and this is exactly what get_user() does, there's no point having two different implementations that are doing the same thing. So, when the Spectre workarounds are required, make __get_user() an alias of get_user(). Acked-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit d09fbb32 upstream. Borrow the x86 implementation of __inttype() to use in get_user() to select an integer type suitable to temporarily hold the result value. This is necessary to avoid propagating the volatile nature of the result argument, which can cause the following warning: lib/iov_iter.c:413:5: warning: optimization may eliminate reads and/or writes to register variables [-Wvolatile-register-var] Acked-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 8c8484a1 upstream. __get_user_error() is used as a fast accessor to make copying structure members as efficient as possible. However, with software PAN and the recent Spectre variant 1, the efficiency is reduced as these are no longer fast accessors. In the case of software PAN, it has to switch the domain register around each access, and with Spectre variant 1, it would have to repeat the access_ok() check for each access. Rather than using __get_user_error() to copy each semops element member, copy each semops element in full using __copy_from_user(). Acked-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 42019fc5 upstream. __get_user_error() is used as a fast accessor to make copying structure members in the signal handling path as efficient as possible. However, with software PAN and the recent Spectre variant 1, the efficiency is reduced as these are no longer fast accessors. In the case of software PAN, it has to switch the domain register around each access, and with Spectre variant 1, it would have to repeat the access_ok() check for each access. Use __copy_from_user() rather than __get_user_err() for individual members when restoring VFP state. Acked-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit c32cd419 upstream. __get_user_error() is used as a fast accessor to make copying structure members in the signal handling path as efficient as possible. However, with software PAN and the recent Spectre variant 1, the efficiency is reduced as these are no longer fast accessors. In the case of software PAN, it has to switch the domain register around each access, and with Spectre variant 1, it would have to repeat the access_ok() check for each access. It becomes much more efficient to use __copy_from_user() instead, so let's use this for the ARM integer registers. Acked-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 10573ae5 upstream. Prevent speculation at the syscall table decoding by clamping the index used to zero on invalid system call numbers, and using the csdb speculative barrier. Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 1d4238c5 upstream. Add an implementation of the array_index_mask_nospec() function for mitigating Spectre variant 1 throughout the kernel. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit a78d1565 upstream. Add assembly and C macros for the new CSDB instruction. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit c44f366e upstream. Warn at error level if the context switching function is not what we are expecting. This can happen with big.Little systems, which we currently do not support. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 10115105 upstream. Add firmware based hardening for cores that require more complex handling in firmware. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit f5fe12b1 upstream. In order to prevent aliasing attacks on the branch predictor, invalidate the BTB or instruction cache on CPUs that are known to be affected when taking an abort on a address that is outside of a user task limit: Cortex A8, A9, A12, A17, A73, A75: flush BTB. Cortex A15, Brahma B15: invalidate icache. If the IBE bit is not set, then there is little point to enabling the workaround. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit e388b802 upstream. When the branch predictor hardening is enabled, firmware must have set the IBE bit in the auxiliary control register. If this bit has not been set, the Spectre workarounds will not be functional. Add validation that this bit is set, and print a warning at alert level if this is not the case. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Boot-tested-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 06c23f5f upstream. Required manual merge of arch/arm/mm/proc-v7.S. Harden the branch predictor against Spectre v2 attacks on context switches for ARMv7 and later CPUs. We do this by: Cortex A9, A12, A17, A73, A75: invalidating the BTB. Cortex A15, Brahma B15: invalidating the instruction cache. Cortex A57 and Cortex A72 are not addressed in this patch. Cortex R7 and Cortex R8 are also not addressed as we do not enforce memory protection on these cores. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit c58d237d upstream. Add a Kconfig symbol for CPUs which are vulnerable to the Spectre attacks. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 9d3a0492 upstream. Add support for per-processor bug checking - each processor function descriptor gains a function pointer for this check, which must not be an __init function. If non-NULL, this will be called whenever a CPU enters the kernel via which ever path (boot CPU, secondary CPU startup, CPU resuming, etc.) This allows processor specific bug checks to validate that workaround bits are properly enabled by firmware via all entry paths to the kernel. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 26602161 upstream. Check for CPU bugs when secondary processors are being brought online, and also when CPUs are resuming from a low power mode. This gives an opportunity to check that processor specific bug workarounds are correctly enabled for all paths that a CPU re-enters the kernel. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit a5b9177f upstream. Prepare the processor bug infrastructure so that it can be expanded to check for per-processor bugs. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit f5683e76 upstream. Add CPU part numbers for Cortex A53, A57, A72, A73, A75 and the Broadcom Brahma B15 CPU. Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 [ Upstream commit 755a8bf5 ] If someone has the silly idea to write something along those lines: extern u64 foo(void); void bar(struct arm_smccc_res *res) { arm_smccc_1_1_smc(0xbad, foo(), res); } they are in for a surprise, as this gets compiled as: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d4000003 smc #0x0 5ac: b4000073 cbz x19, 5b8 <bar+0x30> 5b0: a9000660 stp x0, x1, [x19] 5b4: a9010e62 stp x2, x3, [x19, #16] 5b8: f9400bf3 ldr x19, [sp, #16] 5bc: a8c27bfd ldp x29, x30, [sp], #32 5c0: d65f03c0 ret 5c4: d503201f nop The call to foo "overwrites" the x0 register for the return value, and we end up calling the wrong secure service. A solution is to evaluate all the parameters before assigning anything to specific registers, leading to the expected result: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d28175a0 mov x0, #0xbad 5ac: d4000003 smc #0x0 5b0: b4000073 cbz x19, 5bc <bar+0x34> 5b4: a9000660 stp x0, x1, [x19] 5b8: a9010e62 stp x2, x3, [x19, #16] 5bc: f9400bf3 ldr x19, [sp, #16] 5c0: a8c27bfd ldp x29, x30, [sp], #32 5c4: d65f03c0 ret Reported-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 [ Upstream commit 1d8f5747 ] An unfortunate consequence of having a strong typing for the input values to the SMC call is that it also affects the type of the return values, limiting r0 to 32 bits and r{1,2,3} to whatever was passed as an input. Let's turn everything into "unsigned long", which satisfies the requirements of both architectures, and allows for the full range of return values. Reported-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit eff0e9e1 upstream. We've so far used the PSCI return codes for SMCCC because they were extremely similar. But with the new ARM DEN 0070A specification, "NOT_REQUIRED" (-2) is clashing with PSCI's "PSCI_RET_INVALID_PARAMS". Let's bite the bullet and add SMCCC specific return codes. Users can be repainted as and when required. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit f2d3b2e8 upstream. One of the major improvement of SMCCC v1.1 is that it only clobbers the first 4 registers, both on 32 and 64bit. This means that it becomes very easy to provide an inline version of the SMC call primitive, and avoid performing a function call to stash the registers that would otherwise be clobbered by SMCCC v1.0. Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Tested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit ded4c39e upstream. Function identifiers are a 32bit, unsigned quantity. But we never tell so to the compiler, resulting in the following: 4ac: b26187e0 mov x0, #0xffffffff80000001 We thus rely on the firmware narrowing it for us, which is not always a reasonable expectation. Cc: stable@vger.kernel.org Reported-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit e78eef55 upstream. Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed, let's do that at boot time, and expose the version of the calling convention as part of the psci_ops structure. Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit 09a8d6d4 upstream. In order to call into the firmware to apply workarounds, it is useful to find out whether we're using HVC or SMC. Let's expose this through the psci_ops. Acked-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit 6167ec5c upstream. A new feature of SMCCC 1.1 is that it offers firmware-based CPU workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides BP hardening for CVE-2017-5715. If the host has some mitigation for this issue, report that we deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the host workaround on every guest exit. Tested-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1852110 commit 09e6be12 upstream. The new SMC Calling Convention (v1.1) allows for a reduced overhead when calling into the firmware, and provides a new feature discovery mechanism. Make it visible to KVM guests. Tested-by:
-
Vladimir Murzin authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 4f254638 upstream. Headers linux/irqchip/arm-gic.v3.h and arch/arm/include/asm/kvm_hyp.h are included in virt/kvm/arm/hyp/vgic-v3-sr.c and both define macros called __ACCESS_CP15 and __ACCESS_CP15_64 which obviously creates a conflict. These macros were introduced independently for GIC and KVM and, in fact, do the same thing. As an option we could add prefixes to KVM and GIC version of macros so they won't clash, but it'd introduce code duplication. Alternatively, we could keep macro in, say, GIC header and include it in KVM one (or vice versa), but such dependency would not look nicer. So we follow arm64 way (it handles this via sysreg.h) and move only single set of macros to asm/cp15.h Cc: Russell King <rmk+kernel@armlinux.org.uk> Acked-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 9f73bd8b upstream. Remove the code duplication between put_user() and __put_user(). The code which selected the implementation based upon the pointer size, and declared the local variable to hold the value to be put are common to both implementations. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jens Wiklander authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit e679660d upstream. Switch to use a generic interface for issuing SMC/HVC based on ARM SMC Calling Convention. Removes now the now unused psci-call.S. Acked-by:
Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by:
-
Jens Wiklander authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit 14457459 upstream. Adds implementation for arm-smccc and enables CONFIG_HAVE_SMCCC. Acked-by:
-
Jens Wiklander authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Commit b329f95d upstream. Adds implementation for arm-smccc and enables CONFIG_HAVE_SMCCC for architectures that may support arm-smccc. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. Reviewed-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
-
