kernel.git/arch/arm64/Kconfig, branch linux-4.10.y

irqchip/gicv3-its: Add workaround for QDF2400 ITS erratum 0065

2017-03-22T11:57:03Z

commit 90922a2d03d84de36bf8a9979d62580102f31a92 upstream. On Qualcomm Datacenter Technologies QDF2400 SoCs, the ITS hardware implementation uses 16Bytes for Interrupt Translation Entry (ITE), but reports an incorrect value of 8Bytes in GITS_TYPER.ITTE_size. It might cause kernel memory corruption depending on the number of MSI(x) that are configured and the amount of memory that has been allocated for ITEs in its_create_device(). This patch fixes the potential memory corruption by setting the correct ITE size to 16Bytes. Cc: stable@vger.kernel.org Signed-off-by: Shanker Donthineni Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2016-12-14T00:39:21Z

Pull arm64 updates from Catalin Marinas: - struct thread_info moved off-stack (also touching include/linux/thread_info.h and include/linux/restart_block.h) - cpus_have_cap() reworked to avoid __builtin_constant_p() for static key use (also touching drivers/irqchip/irq-gic-v3.c) - uprobes support (currently only for native 64-bit tasks) - Emulation of kernel Privileged Access Never (PAN) using TTBR0_EL1 switching to a reserved page table - CPU capacity information passing via DT or sysfs (used by the scheduler) - support for systems without FP/SIMD (IOW, kernel avoids touching these registers; there is no soft-float ABI, nor kernel emulation for AArch64 FP/SIMD) - handling of hardware watchpoint with unaligned addresses, varied lengths and offsets from base - use of the page table contiguous hint for kernel mappings - hugetlb fixes for sizes involving the contiguous hint - remove unnecessary I-cache invalidation in flush_cache_range() - CNTHCTL_EL2 access fix for CPUs with VHE support (ARMv8.1) - boot-time checks for writable+executable kernel mappings - simplify asm/opcodes.h and avoid including the 32-bit ARM counterpart and make the arm64 kernel headers self-consistent (Xen headers patch merged separately) - Workaround for broken .inst support in certain binutils versions * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (60 commits) arm64: Disable PAN on uaccess_enable() arm64: Work around broken .inst when defective gas is detected arm64: Add detection code for broken .inst support in binutils arm64: Remove reference to asm/opcodes.h arm64: Get rid of asm/opcodes.h arm64: smp: Prevent raw_smp_processor_id() recursion arm64: head.S: Fix CNTHCTL_EL2 access on VHE system arm64: Remove I-cache invalidation from flush_cache_range() arm64: Enable HIBERNATION in defconfig arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN arm64: xen: Enable user access before a privcmd hvc call arm64: Handle faults caused by inadvertent user access with PAN enabled arm64: Disable TTBR0_EL1 during normal kernel execution arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1 arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro arm64: Factor out PAN enabling/disabling into separate uaccess_* macros arm64: Update the synchronous external abort fault description selftests: arm64: add test for unaligned/inexact watchpoint handling arm64: Allow hw watchpoint of length 3,5,6 and 7 arm64: hw_breakpoint: Handle inexact watchpoint addresses ...

ACPI / APEI / ARM64: APEI initial support for ARM64

2016-12-01T23:24:34Z

This patch provides APEI arch-specific bits for ARM64 Meanwhile, (1) Move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to a generic place. (2) Select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64, because arch_apei_get_mem_attribute is using efi_mem_attributes() on ARM64. Signed-off-by: Tomasz Nowicki Tested-by: Jonathan (Zhixiong) Zhang Signed-off-by: Fu Wei [ Fu Wei: improve && upstream ] Acked-by: Hanjun Guo Tested-by: Tyler Baicar Acked-by: Will Deacon Reviewed-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki

arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN

2016-11-21T18:48:55Z

This patch adds the Kconfig option to enable support for TTBR0 PAN emulation. The option is default off because of a slight performance hit when enabled, caused by the additional TTBR0_EL1 switching during user access operations or exception entry/exit code. Cc: Will Deacon Cc: James Morse Cc: Kees Cook Cc: Mark Rutland Signed-off-by: Catalin Marinas

arm64: split thread_info from task stack

2016-11-11T18:25:46Z

This patch moves arm64's struct thread_info from the task stack into task_struct. This protects thread_info from corruption in the case of stack overflows, and makes its address harder to determine if stack addresses are leaked, making a number of attacks more difficult. Precise detection and handling of overflow is left for subsequent patches. Largely, this involves changing code to store the task_struct in sp_el0, and acquire the thread_info from the task struct. Core code now implements current_thread_info(), and as noted in this relies on offsetof(task_struct, thread_info) == 0, enforced by core code. This change means that the 'tsk' register used in entry.S now points to a task_struct, rather than a thread_info as it used to. To make this clear, the TI_* field offsets are renamed to TSK_TI_*, with asm-offsets appropriately updated to account for the structural change. Userspace clobbers sp_el0, and we can no longer restore this from the stack. Instead, the current task is cached in a per-cpu variable that we can safely access from early assembly as interrupts are disabled (and we are thus not preemptible). Both secondary entry and idle are updated to stash the sp and task pointer separately. Signed-off-by: Mark Rutland Tested-by: Laura Abbott Cc: AKASHI Takahiro Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: James Morse Cc: Kees Cook Cc: Suzuki K Poulose Cc: Will Deacon Signed-off-by: Catalin Marinas

arm64: Add uprobe support

2016-11-07T18:15:21Z

This patch adds support for uprobe on ARM64 architecture. Unit tests for following have been done so far and they have been found working 1. Step-able instructions, like sub, ldr, add etc. 2. Simulation-able like ret, cbnz, cbz etc. 3. uretprobe 4. Reject-able instructions like sev, wfe etc. 5. trapped and abort xol path 6. probe at unaligned user address. 7. longjump test cases Currently it does not support aarch32 instruction probing. Signed-off-by: Pratyush Anand Signed-off-by: Catalin Marinas

arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=y

2016-10-17T15:24:02Z

The RANDOMIZE_MODULE_REGION_FULL Kconfig option allows KASLR to be configured in such a way that kernel modules and the core kernel are allocated completely independently, which implies that modules are likely to require branches via PLT entries to reach the core kernel. The dynamic ftrace code does not expect that, and assumes that it can patch module code to perform a relative branch to anywhere in the core kernel. This may result in errors such as branch_imm_common: offset out of range ------------[ cut here ]------------ WARNING: CPU: 3 PID: 196 at kernel/trace/ftrace.c:1995 ftrace_bug+0x220/0x2e8 Modules linked in: CPU: 3 PID: 196 Comm: systemd-udevd Not tainted 4.8.0-22-generic #24 Hardware name: AMD Seattle/Seattle, BIOS 10:34:40 Oct 6 2016 task: ffff8d1bef7dde80 task.stack: ffff8d1bef6b0000 PC is at ftrace_bug+0x220/0x2e8 LR is at ftrace_process_locs+0x330/0x430 So make RANDOMIZE_MODULE_REGION_FULL mutually exclusive with DYNAMIC_FTRACE at the Kconfig level. Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon

atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

2016-10-08T01:46:30Z

This came to light when implementing native 64-bit atomics for ARCv2. The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE to check whether atomic64_dec_if_positive() is available. It seems it was needed when not every arch defined it. However as of current code the Kconfig option seems needless - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a generic definition of API is present lib/atomic64.c - arches with native 64-bit atomics select it in arch/*/Kconfig and define the API in their headers So I see no point in keeping the Kconfig option Compile tested for: - blackfin (CONFIG_GENERIC_ATOMIC64) - x86 (!CONFIG_GENERIC_ATOMIC64) - ia64 Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.com Signed-off-by: Vineet Gupta Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Ralf Baechle Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: "David S. Miller" Cc: Chris Metcalf Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Vineet Gupta Cc: Zhaoxiu Zeng Cc: Linus Walleij Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Herbert Xu Cc: Ming Lin Cc: Arnd Bergmann Cc: Geert Uytterhoeven Cc: Peter Zijlstra Cc: Borislav Petkov Cc: Andi Kleen Cc: Boqun Feng Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

arm64 Kconfig: select gigantic page

2016-10-08T01:46:29Z

Arm64 supports gigantic pages after commit 084bd29810a5 ("ARM64: mm: HugeTLB support.") however, it can only be allocated at boottime and can't be freed. This patch selects ARCH_HAS_GIGANTIC_PAGE to make gigantic pages can be allocated and freed at runtime for arch arm64. Link: http://lkml.kernel.org/r/1475227569-63446-3-git-send-email-xieyisheng1@huawei.com Signed-off-by: Yisheng Xie Acked-by: Michal Hocko Acked-by: Catalin Marinas Acked-by: Hillf Danton Cc: Hanjun Guo Cc: Will Deacon Cc: Dave Hansen Cc: Sudeep Holla Cc: Mark Rutland Cc: Rob Herring Cc: Mike Kravetz Cc: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2016-10-05T18:49:09Z

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.9 series: Subsystem improvements: - do away with the last users of the obsolete Kconfig options ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter always sounded like an item on a wishlist to Santa Claus to me). We can now select GPIOLIB and be done with it, for all archs. After some struggle it even work on UM. Not that it has GPIO, but if it wants to, it can select the library. - continued efforts to make drivers properly either tristate or bool. - introduce a warning for drivers assigning default triggers to their irqchip lines when probed from device tree, so we find and fix these ambigous drivers. It is agreed that in the OF config path, the device tree defines trigger characteristics. - the same warning, mutatis mutandis, for ACPI-probed GPIO irqchips. - we introduce the ability to mark certain IRQ lines as "unusable" as they can be taken by BIOS/firmware, unrouted in silicon and generally nasty if you use them, and such things. This is put to good use in the STMPE driver and also in the Cherryview pin control driver. - a new "mockup" virtual GPIO device that can be used for testing. The plan is to add unit tests under tools/* for exercising this device and verify that the kernel code paths are working as they should. - make memory-mapped I/O-drivers depend on HAS_IOMEM. This was implicit all the time, but when people started building UM with allyesconfig or allmodconfig it exploded in their face. - move some stray bits of device tree and ACPI HW description callbacks down into their respective implementation silo. These were causing issues when compiling on !HAS_IOMEM as well, so now eventually UM compiles the GPIOLIB library if it wants to. New drivers: - new driver for the Aspeed GPIO front-end companion to the pin controller merged through the pin control tree. - new driver for the LP873x PMIC GPIO portions. - new driver for Technologic Systems' I2C FPGA GPIO such as TS4900, TS-7970, TS-7990 and TS-4100. - new driver for the Broadcom BCM63xx series including BCM6338 and BCM6345. - new driver for the Intel WhiskeyCove PMIC GPIO. - new driver for the Allwinner AXP209 PMIC GPIO portions. - new driver for Diamond Systems 48 line GPIO-MM, another of these port-mapped I/O expansion cards. - support the STMicroelectronics STMPE1600 variant in the STMPE driver. Driver improvements: - the STMPE driver now supports rising/falling edge detection properly for IRQs. - the PCA954x will now fetch and enable its VCC regulator properly. - major rework of the PCA953x driver with the goal of eventually switching it over to use regmap and thus modernize it even more. - switch the IOP driver to use the generic MMIO GPIO library. - move the ages old HTC EGPIO (extended GPIO) GPIO expander driver over to this subsystem from MFD, achieveing some separation of concerns" * tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (81 commits) gpio: add missing static inline gpio: OF: localize some gpiochip init functions gpio: acpi: separation of concerns gpio: OF: separation of concerns gpio: make memory-mapped drivers depend on HAS_IOMEM gpio: stmpe: use BIT() macro gpio: stmpe: forbid unused lines to be mapped as IRQs mfd/gpio: Move HTC GPIO driver to GPIO subsystem gpio: MAINTAINERS: Add an entry for GPIO mockup driver gpio/mockup: add virtual gpio device gpio: Added zynq specific check for special pins on bank zero gpio: axp209: Implement get_direction gpio: aspeed: remove redundant return value check gpio: loongson1: remove redundant return value check ARM: omap2: fix missing include gpio: tc3589x: fix up complaints on unsigned gpio: tc3589x: add .get_direction() and small cleanup gpio: f7188x: use gpiochip_get_data instead of container_of gpio: tps65218: use devm_gpiochip_add_data() for gpio registration gpio: aspeed: fix return value check in aspeed_gpio_probe() ...