- Feb 28, 2018
-
-
Shawn Guo authored
It fixes LS family SoCs device tree dtc warning in IFC child nodes. Warning (simple_bus_reg): Node /soc/ifc@1530000/nor@0,0 simple-bus unit address format error, expected "0" Warning (simple_bus_reg): Node /soc/ifc@1530000/nand@1,0 simple-bus unit address format error, expected "100000000" Warning (simple_bus_reg): Node /soc/ifc@1530000/board-control@2,0 simple-bus unit address format error, expected "200000000" Signed-off-by:Shawn Guo <shawnguo@kernel.org>
-
- Feb 24, 2018
-
-
Yuantian Tang authored
According to PSCI standard v0.2, for CPU_SUSPEND call, which is used by cpu idle framework, bit[16] of state parameter must be 0. So update bit[16] of property 'arm,psci-suspend-param', which is used as state parameter, to 0. Signed-off-by:
Tang Yuantian <andy.tang@nxp.com> Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Signed-off-by:
-
Yuantian Tang authored
Signed-off-by:
-
Yuantian Tang authored
Signed-off-by:
-
- Feb 12, 2018
-
-
Fabio Estevam authored
The 'reg' property should match the corresponding @ address, so fix it accordingly. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Fabio Estevam authored
Pass unit name to dspi child nodes to fix the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dtb: Warning (unit_address_vs_reg): Node /soc/dspi@2100000/n25q128a has a reg or ranges property, but no unit name arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dtb: Warning (unit_address_vs_reg): Node /soc/dspi@2100000/sst25wf040b has a reg or ranges property, but no unit name arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dtb: Warning (unit_address_vs_reg): Node /soc/dspi@2100000/en25s64 has a reg or ranges property, but no unit name Signed-off-by:
-
Fabio Estevam authored
Move cpu_thermal node from soc node to root node. cpu_thermal node does not have any register properties and thus shouldn't be placed on the bus. This fixes the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property Signed-off-by:
-
Fabio Estevam authored
Move cpu_thermal node from soc node to root node. cpu_thermal node does not have any register properties and thus shouldn't be placed on the bus. This fixes the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property Signed-off-by:
-
Fabio Estevam authored
Move cpu_thermal node from soc node to root node. cpu_thermal node does not have any register properties and thus shouldn't be placed on the bus. This fixes the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property Signed-off-by:
-
Fabio Estevam authored
Move cpu_thermal node from soc node to root node. cpu_thermal node does not have any register properties and thus shouldn't be placed on the bus. This fixes the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property Signed-off-by:
-
Fabio Estevam authored
Move cpu_thermal node from soc node to root node. cpu_thermal node does not have any register properties and thus shouldn't be placed on the bus. This fixes the following build warnings with W=1: arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property Signed-off-by:
-
Roy Pledge authored
ARM DPAA1 (LS1043 and LS1046) have 10 QBMan portals (indexed 0-9) Enable the one that is missing in the device trees. Signed-off-by:
Roy Pledge <roy.pledge@nxp.com> Signed-off-by:
-
Zhang Ying-22455 authored
There are eight cores in ls1088a and each core has an watchdog, ls1088a can use sp805-wdt driver, so we just add DT node for it. Signed-off-by:
Zhang Ying-22455 <ying.zhang22455@nxp.com> Signed-off-by:
-
- Feb 07, 2018
-
-
Prarit Bhargava authored
SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup an early console. General fixes include updating Documentation & Kconfig (for x86), updating comments, and changing parse_spcr() to acpi_parse_spcr(), and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be more descriptive. On x86, many systems have a valid SPCR table but the table version is not 2 so the table version check must be a warning. On ARM64 when the kernel parameter earlycon is used both the early console and console are enabled. On x86, only the earlycon should be enabled by by default. Modify acpi_parse_spcr() to allow options for initializing the early console and console separately. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Reviewed-by:
Mark Salter <msalter@redhat.com> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Yury Norov authored
with bitmap_{from,to}_arr32 over the kernel. Additionally to it: * __check_eq_bitmap() now takes single nbits argument. * __check_eq_u32_array is not used in new test but may be used in future. So I don't remove it here, but annotate as __used. Tested on arm64 and 32-bit BE mips. [arnd@arndb.de: perf: arm_dsu_pmu: convert to bitmap_from_arr32] Link: http://lkml.kernel.org/r/20180201172508.5739-2-ynorov@caviumnetworks.com [ynorov@caviumnetworks.com: fix net/core/ethtool.c] Link: http://lkml.kernel.org/r/20180205071747.4ekxtsbgxkj5b2fz@yury-thinkpad Link: http://lkml.kernel.org/r/20171228150019.27953-2-ynorov@caviumnetworks.com Signed-off-by:Yury Norov <ynorov@caviumnetworks.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: David Decotigny <decot@googlers.com>, Cc: David S. Miller <davem@davemloft.net>, Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrey Konovalov authored
Right now the fact that KASAN uses a single shadow byte for 8 bytes of memory is scattered all over the code. This change defines KASAN_SHADOW_SCALE_SHIFT early in asm include files and makes use of this constant where necessary. [akpm@linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/34937ca3b90736eaad91b568edf5684091f662e3.1515775666.git.andreyknvl@google.com Signed-off-by:
Andrey Konovalov <andreyknvl@google.com> Acked-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
- Feb 06, 2018
-
-
Marc Zyngier authored
Now that we've standardised on SMCCC v1.1 to perform the branch prediction invalidation, let's drop the previous band-aid. If vendors haven't updated their firmware to do SMCCC 1.1, they haven't updated PSCI either, so we don't loose anything. Tested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Marc Zyngier authored
Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. It is lovely. Really. Tested-by:
-
Marc Zyngier authored
We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible. So let's intercept it as early as we can by testing for the function call number as soon as we've identified a HVC call coming from the guest. Tested-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
We're about to need kvm_psci_version in HYP too. So let's turn it into a static inline, and pass the kvm structure as a second parameter (so that HYP can do a kern_hyp_va on it). Tested-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
As we're about to update the PSCI support, and because I'm lazy, let's move the PSCI include file to include/kvm so that both ARM architectures can find it. Acked-by:
-
Marc Zyngier authored
When handling an SMC trap, the "preferred return address" is set to that of the SMC, and not the next PC (which is a departure from the behaviour of an SMC that isn't trapped). Increment PC in the handler, as the guest is otherwise forever stuck... Cc: stable@vger.kernel.org Fixes: acfb3b88 ("arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls") Reviewed-by:
-
Marc Zyngier authored
KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Signed-off-by:
-
Will Deacon authored
It is possible to take an IRQ from EL0 following a branch to a kernel address in such a way that the IRQ is prioritised over the instruction abort. Whilst an attacker would need to get the stars to align here, it might be sufficient with enough calibration so perform BP hardening in the rare case that we see a kernel address in the ELR when handling an IRQ from EL0. Reported-by:
Dan Hettena <dhettena@nvidia.com> Reviewed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
Software-step and PC alignment fault exceptions have higher priority than instruction abort exceptions, so apply the BP hardening hooks there too if the user PC appears to reside in kernel space. Reported-by:
-
Will Deacon authored
The arm64 futex code has some explicit dereferencing of user pointers where performing atomic operations in response to a futex command. This patch uses masking to limit any speculative futex operations to within the user address space. Signed-off-by:
-
Will Deacon authored
Like we've done for get_user and put_user, ensure that user pointers are masked before invoking the underlying __arch_{clear,copy_*}_user operations. Signed-off-by: -
Will Deacon authored
access_ok isn't an expensive operation once the addr_limit for the current thread has been loaded into the cache. Given that the initial access_ok check preceding a sequence of __{get,put}_user operations will take the brunt of the miss, we can make the __* variants identical to the full-fat versions, which brings with it the benefits of address masking. The likely cost in these sequences will be from toggling PAN/UAO, which we can address later by implementing the *_unsafe versions. Reviewed-by:Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Will Deacon authored
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. Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Will Deacon authored
In a similar manner to array_index_mask_nospec, this patch introduces an assembly macro (mask_nospec64) which can be used to bound a value under speculation. This macro is then used to ensure that the indirect branch through the syscall table is bounded under speculation, with out-of-range addresses speculating as calls to sys_io_setup (0). Reviewed-by:
-
Robin Murphy authored
Similarly to x86, mitigate speculation past an access_ok() check by masking the pointer against the address limit before use. Even if we don't expect speculative writes per se, it is plausible that a CPU may still speculate at least as far as fetching a cache line for writing, hence we also harden put_user() and clear_user() for peace of mind. Signed-off-by:
-
Robin Murphy authored
Currently, USER_DS represents an exclusive limit while KERNEL_DS is inclusive. In order to do some clever trickery for speculation-safe masking, we need them both to behave equivalently - there aren't enough bits to make KERNEL_DS exclusive, so we have precisely one option. This also happens to correct a longstanding false negative for a range ending on the very top byte of kernel memory. Mark Rutland points out that we've actually got the semantics of addresses vs. segments muddled up in most of the places we need to amend, so shuffle the {USER,KERNEL}_DS definitions around such that we can correct those properly instead of just pasting "-1"s everywhere. Signed-off-by: -
Robin Murphy authored
Provide an optimised, assembly implementation of array_index_mask_nospec() for arm64 so that the compiler is not in a position to transform the code in ways which affect its ability to inhibit speculation (e.g. by introducing conditional branches). This is similar to the sequence used by x86, modulo architectural differences in the carry/borrow flags. Reviewed-by:
-
Will Deacon authored
For CPUs capable of data value prediction, CSDB waits for any outstanding predictions to architecturally resolve before allowing speculative execution to continue. Provide macros to expose it to the arch code. Reviewed-by:
-
Will Deacon authored
The identity map is mapped as both writeable and executable by the SWAPPER_MM_MMUFLAGS and this is relied upon by the kpti code to manage a synchronisation flag. Update the .pushsection flags to reflect the actual mapping attributes. Reported-by:
-
Will Deacon authored
pte_to_phys lives in assembler.h and takes its destination register as the first argument. Move phys_to_pte out of head.S to sit with its counterpart and rejig it to follow the same calling convention. Signed-off-by:
-
Will Deacon authored
We don't fully understand the Cavium ThunderX erratum, but it appears that mapping the kernel as nG can lead to horrible consequences such as attempting to execute userspace from kernel context. Since kpti isn't enabled for these CPUs anyway, simplify the comment justifying the lack of post_ttbr_update_workaround in the exception trampoline. Signed-off-by:
-
Will Deacon authored
Since AArch64 assembly instructions take the destination register as their first operand, do the same thing for the phys_to_ttbr macro. Acked-by:
-
