- 31 Jul, 2018 2 commits
-
-
Laura Abbott authored
arm64 uses the full KBUILD_CFLAGS for building libstub as opposed to x86 which doesn't. This means that x86 doesn't pick up the gcc-plugins. We need to disable the stackleak plugin but doing this unconditionally breaks x86 build since it doesn't have any plugins. Switch to disabling the stackleak plugin for arm64 only. Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Ard Biesheuvel authored
When kernel mode NEON was first introduced to the arm64 kernel, every call to kernel_neon_begin()/_end() stacked resp. unstacked the entire NEON register file, making it worthwile to reduce the number of used NEON registers to a bare minimum, and only stack those. kernel_neon_begin_partial() was introduced for this purpose, but after the refactoring for SVE and other changes, it no longer exists and was simply #define'd to kernel_neon_begin() directly. In the mean time, all users have been updated, so let's remove the fallback macro. Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
- 30 Jul, 2018 2 commits
-
-
Dave Kleikamp authored
machine_kexec flushes the reboot_code_buffer from the icache after stopping the other cpus. Commit 3b8c9f1c ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") added an IPI call to flush_icache_range, which causes a hang here, so replace the call with __flush_icache_range Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
We always run userspace with interrupts enabled, but with the recent conversion of the syscall entry/exit code to C, we don't inform the hardirq tracing code that interrupts are about to become enabled by virtue of restoring the EL0 SPSR. This patch ensures that trace_hardirqs_on() is called on the syscall return path when we return to the assembly code with interrupts still disabled. Fixes: f37099b6 ("arm64: convert syscall trace logic to C") Reported-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
-
- 27 Jul, 2018 2 commits
-
-
Will Deacon authored
Merge branch 'for-next/perf' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into aarch64/for-next/core Pull in arm perf updates, including support for 64-bit (chained) event counters and some non-critical fixes for some of the system PMU drivers. Signed-off-by:
-
Ben Hutchings authored
The xen-privcmd driver, which can be modular, calls set_pte_at() which in turn may call __sync_icache_dcache(). The call to __sync_icache_dcache() may be optimised out because it is conditional on !pte_special(), and xen-privcmd calls pte_mkspecial(). But it seems unwise to rely on this optimisation. Fixes: 3ad08765 ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
- 26 Jul, 2018 3 commits
-
-
Sudeep Holla authored
Instead of checking the return value of platform_get_resource(), we can use devm_ioremap_resource() which has the NULL pointer check and the memory region requesting. devm_ioremap_resource is designed to replace calls to devm_request_mem_region followed by devm_ioremap, so let's use the same. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Laura Abbott authored
This adds support for the STACKLEAK gcc plugin to arm64 by implementing stackleak_check_alloca(), based heavily on the x86 version, and adding the two helpers used by the stackleak common code: current_top_of_stack() and on_thread_stack(). The stack erasure calls are made at syscall returns. Additionally, this disables the plugin in hypervisor and EFI stub code, which are out of scope for the protection. Acked-by:
Alexander Popov <alex.popov@linux.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
-
Laura Abbott authored
In preparation for enabling the stackleak plugin on arm64, we need a way to get the bounds of the current stack. Extend on_accessible_stack to get this information. Acked-by:
-
- 24 Jul, 2018 2 commits
-
-
Shaokun Zhang authored
MT bit in MPIDR_EL1 is now supported in certain HiSilicon platforms, so the mapping between sccl_id/ccl_id and affinity level needs to be updated from the generic encoding we originally used. Cc: John Garry <john.garry@huawei.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> [will: fixed comment] Signed-off-by:
-
Arnd Bergmann authored
Kconfig reports a warning on x86 builds after the ARM64 dependency was added. drivers/acpi/Kconfig:6:error: recursive dependency detected! drivers/acpi/Kconfig:6: symbol ACPI depends on EFI This rephrases the dependency to keep the ARM64 details out of the shared Kconfig file, so Kconfig no longer gets confused by it. For consistency, all three architectures that support ACPI now select ARCH_SUPPORTS_ACPI in exactly the configuration in which they allow it. We still need the 'default x86', as each one wants a different default: default-y on x86, default-n on arm64, and always-y on ia64. Fixes: 5bcd4408 ("drivers: acpi: add dependency of EFI for arm64") Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 23 Jul, 2018 8 commits
-
-
Will Deacon authored
Hook up arm64 support to the rseq selftests. Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
-
AKASHI Takahiro authored
This is a fix against the issue that crash dump kernel may hang up during booting, which can happen on any ACPI-based system with "ACPI Reclaim Memory." (kernel messages after panic kicked off kdump) (snip...) Bye! (snip...) ACPI: Core revision 20170728 pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 Internal error: Oops: 96000021 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 task: ffff000008d05180 task.stack: ffff000008cc0000 PC is at acpi_ns_lookup+0x25c/0x3c0 LR is at acpi_ds_load1_begin_op+0xa4/0x294 (snip...) Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) Call trace: (snip...) [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0 [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294 [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198 [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270 [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8 [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8 [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184 [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68 [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264 [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0 [<ffff000008badc20>] acpi_early_init+0x9c/0xd0 [<ffff000008b70d50>] start_kernel+0x3b4/0x43c Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) ---[ end trace c46ed37f9651c58e ]--- Kernel panic - not syncing: Fatal exception Rebooting in 10 seconds.. (diagnosis) * This fault is a data abort, alignment fault (ESR=0x96000021) during reading out ACPI table. * Initial ACPI tables are normally stored in system ram and marked as "ACPI Reclaim memory" by the firmware. * After the commit f56ab9a5 ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP"), those regions are differently handled as they are "memblock-reserved", without NOMAP bit. * So they are now excluded from device tree's "usable-memory-range" which kexec-tools determines based on a current view of /proc/iomem. * When crash dump kernel boots up, it tries to accesses ACPI tables by mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap() since they are no longer part of mapped system ram. * Given that ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), any unaligned access to ACPI tables can cause a fatal panic. With this patch, acpi_os_ioremap() always honors memory attribute information provided by the firmware (EFI) and retaining cacheability allows the kernel safe access to ACPI tables. Signed-off-by:
AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by:
James Morse <james.morse@arm.com> Reviewed-by:
-
AKASHI Takahiro authored
Under the current implementation, UEFI memory map will be mapped and made available in virtual mappings only if runtime services are enabled. But in a later patch, we want to use UEFI memory map in acpi_os_ioremap() to create mappings of ACPI tables using memory attributes described in UEFI memory map. See the following commit: arm64: acpi: fix alignment fault in accessing ACPI tables So, as a first step, arm_enter_runtime_services() is modified, alongside Ard's patch[1], so that UEFI memory map will not be freed even if efi=noruntime. [1] https://marc.info/?l=linux-efi&m=152930773507524&w=2Signed-off-by: -
Ard Biesheuvel authored
The BGRT code validates the contents of the table against the UEFI memory map, and so it expects it to be mapped when the code runs. On ARM, this is currently not the case, since we tear down the early mapping after efi_init() completes, and only create the permanent mapping in arm_enable_runtime_services(), which executes as an early initcall, but still leaves a window where the UEFI memory map is not mapped. So move the call to efi_memmap_unmap() from efi_init() to arm_enable_runtime_services(). Signed-off-by:
-
AKASHI Takahiro authored
As Ard suggested, CONFIG_ACPI && !CONFIG_EFI doesn't make sense on arm64, while CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN doesn't make sense either. As CONFIG_EFI already has a dependency of !CONFIG_CPU_BIG_ENDIAN, it is good enough to add a dependency of CONFIG_EFI to avoid any useless combination of configuration. This bug, reported by Will, will be revealed when my patch series, "arm64: kexec,kdump: fix boot failures on acpi-only system," is applied and the kernel is built under allmodconfig. Signed-off-by:
-
James Morse authored
There has been some confusion around what is necessary to prevent kexec overwriting important memory regions. memblock: reserve, or nomap? Only memblock nomap regions are reported via /proc/iomem, kexec's user-space doesn't know about memblock_reserve()d regions. Until commit f56ab9a5 ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved and thus possible for kexec to overwrite with the new kernel or initrd. But this was always broken, as the UEFI memory map is also reserved and not marked as nomap. Exporting both nomap and reserved memblock types is a nuisance as they live in different memblock structures which we can't walk at the same time. Take a second walk over memblock.reserved and add new 'reserved' subnodes for the memblock_reserved() regions that aren't already described by the existing code. (e.g. Kernel Code) We use reserve_region_with_split() to find the gaps in existing named regions. This handles the gap between 'kernel code' and 'kernel data' which is memblock_reserve()d, but already partially described by request_standard_resources(). e.g.: | 80000000-dfffffff : System RAM | 80080000-80ffffff : Kernel code | 81000000-8158ffff : reserved | 81590000-8237efff : Kernel data | a0000000-dfffffff : Crash kernel | e00f0000-f949ffff : System RAM reserve_region_with_split needs kzalloc() which isn't available when request_standard_resources() is called, use an initcall. Reported-by:
Bhupesh Sharma <bhsharma@redhat.com> Reported-by:
Tyler Baicar <tbaicar@codeaurora.org> Suggested-by:
-
Olof Johansson authored
Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in particular. So, probe for whether it's available and use the previous (linux) targets if it isn't. Reported-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Mark Rutland authored
It's possible for userspace to control idx. Sanitize idx when using it as an array index, to inhibit the potential spectre-v1 write gadget. Found by smatch. Signed-off-by:
-
- 12 Jul, 2018 21 commits
-
-
Will Deacon authored
syscall_trace_{enter,exit} are only called from C code, so drop the asmlinkage qualifier from their definitions. Signed-off-by: -
Mark Rutland authored
To minimize the risk of userspace-controlled values being used under speculation, this patch adds pt_regs based syscall wrappers for arm64, which pass the minimum set of required userspace values to syscall implementations. For each syscall, a wrapper which takes a pt_regs argument is automatically generated, and this extracts the arguments before calling the "real" syscall implementation. Each syscall has three functions generated: * __do_<compat_>sys_<name> is the "real" syscall implementation, with the expected prototype. * __se_<compat_>sys_<name> is the sign-extension/narrowing wrapper, inherited from common code. This takes a series of long parameters, casting each to the requisite types required by the "real" syscall implementation in __do_<compat_>sys_<name>. This wrapper *may* not be necessary on arm64 given the AAPCS rules on unused register bits, but it seemed safer to keep the wrapper for now. * __arm64_<compat_>_sys_<name> takes a struct pt_regs pointer, and extracts *only* the relevant register values, passing these on to the __se_<compat_>sys_<name> wrapper. The syscall invocation code is updated to handle the calling convention required by __arm64_<compat_>_sys_<name>, and passes a single struct pt_regs pointer. The compiler can fold the syscall implementation and its wrappers, such that the overhead of this approach is minimized. Note that we play games with sys_ni_syscall(). It can't be defined with SYSCALL_DEFINE0() because we must avoid the possibility of error injection. Additionally, there are a couple of locations where we need to call it from C code, and we don't (currently) have a ksys_ni_syscall(). While it has no wrapper, passing in a redundant pt_regs pointer is benign per the AAPCS. When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is defines for sys_ni_syscall(). Since we need to treat it differently for in-kernel calls and the syscall tables, the prototype is defined as-required. The wrappers are largely the same as their x86 counterparts, but simplified as we don't have a variety of compat calling conventions that require separate stubs. Unlike x86, we have some zero-argument compat syscalls, and must define COMPAT_SYSCALL_DEFINE0() to ensure that these are also given an __arm64_compat_sys_ prefix. Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Reviewed-by:
-
Mark Rutland authored
In preparation for converting to pt_regs syscall wrappers, convert our existing compat wrappers to C. This will allow the pt_regs wrappers to be automatically generated, and will allow for the compat register manipulation to be folded in with the pt_regs accesses. To avoid confusion with the upcoming pt_regs wrappers and existing compat wrappers provided by core code, the C wrappers are renamed to compat_sys_aarch32_<syscall>. With the assembly wrappers gone, we can get rid of entry32.S and the associated boilerplate. Note that these must call the ksys_* syscall entry points, as the usual sys_* entry points will be modified to take a single pt_regs pointer argument. Signed-off-by:
-
Mark Rutland authored
We don't currently annotate our mmap implementation as a syscall, as we need to do to use pt_regs syscall wrappers. Let's mark it as a real syscall. There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
We don't currently annotate our various sigreturn functions as syscalls, as we need to do to use pt_regs syscall wrappers. Let's mark them as real syscalls. For compat_sys_sigreturn and compat_sys_rt_sigreturn, this changes the return type from int to long, matching the prototypes in sys32.c. Signed-off-by:
-
Mark Rutland authored
With pt_regs syscall wrappers, the calling convention for sys_personality() will change. Use ksys_personality(), which is functionally equivalent. Signed-off-by:
-
Mark Rutland authored
Using this helper allows us to avoid the in-kernel calls to the compat_sys_{f,}statfs64() sycalls, as are necessary for parameter mangling in arm64's compat handling. Following the example of ksys_* functions, kcompat_sys_* functions are intended to be a drop-in replacement for their compat_sys_* counterparts, with the same calling convention. This is necessary to enable conversion of arm64's syscall handling to use pt_regs wrappers. Signed-off-by: -
Mark Rutland authored
Using this helper allows us to avoid the in-kernel call to the sys_personality() syscall. The ksys_ prefix denotes that this function is meant as a drop-in replacement for the syscall. In particular, it uses the same calling convention as sys_personality(). Since ksys_personality is trivial, it is implemented directly in <linux/syscalls.h>, as we do for ksys_close() and friends. This helper is necessary to enable conversion of arm64's syscall handling to use pt_regs wrappers. Signed-off-by:
-
Mark Rutland authored
Our syscall tables are aligned to 4096 bytes, which allowed their addresses to be generated with a single adrp in entry.S. This has the unfortunate property of wasting space in .rodata for the necessary padding. Now that the address is generated by C code, we can rely on the compiler to do the right thing, and drop the alignemnt. Signed-off-by:
-
Mark Rutland authored
We can zero GPRs x0 - x29 upon entry from EL0 to make it harder for userspace to control values consumed by speculative gadgets. We don't blat x30, since this is stashed much later, and we'll blat it before invoking C code. Signed-off-by:
-
Mark Rutland authored
Now that all of the syscall logic works on the saved pt_regs, apply_ssbd can safely corrupt x0-x3 in the entry paths, and we no longer need to restore them. So let's remove the logic doing so. With that logic gone, we can fold the branch target into the macro, so that callers need not deal with this. GAS provides \@, which provides a unique value per macro invocation, which we can use to create a unique label. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Acked-by:
-
Mark Rutland authored
Now that syscalls are invoked with pt_regs, we no longer need to ensure that the argument regsiters are live in the entry assembly, and it's fine to not restore them after context_tracking_user_exit() has corrupted them. Signed-off-by:
-
Mark Rutland authored
Now that the syscall invocation logic is in C, we can migrate the rest of the syscall entry logic over, so that the entry assembly needn't look at the register values at all. The SVE reset across syscall logic now unconditionally clears TIF_SVE, but sve_user_disable() will only write back to CPACR_EL1 when SVE is actually enabled. Signed-off-by:
-
Mark Rutland authored
Currently syscall tracing is a tricky assembly state machine, which can be rather difficult to follow, and even harder to modify. Before we start fiddling with it for pt_regs syscalls, let's convert it to C. This is not intended to have any functional change. Signed-off-by:
-
Mark Rutland authored
As a first step towards invoking syscalls with a pt_regs argument, convert the raw syscall invocation logic to C. We end up with a bit more register shuffling, but the unified invocation logic means we can unify the tracing paths, too. Previously, assembly had to open-code calls to ni_sys() when the system call number was out-of-bounds for the relevant syscall table. This case is now handled by invoke_syscall(), and the assembly no longer need to handle this case explicitly. This allows the tracing paths to be simplified and unified, as we no longer need the __ni_sys_trace path and the __sys_trace_return label. This only converts the invocation of the syscall. The rest of the syscall triage and tracing is left in assembly for now, and will be converted in subsequent patches. Signed-off-by:
-
Mark Rutland authored
In preparation for invoking arbitrary syscalls from C code, let's define a type for an arbitrary syscall, matching the parameter passing rules of the AAPCS. There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
The arm64 sigreturn* syscall handlers are non-standard. Rather than taking a number of user parameters in registers as per the AAPCS, they expect the pt_regs as their sole argument. To make this work, we override the syscall definitions to invoke wrappers written in assembly, which mov the SP into x0, and branch to their respective C functions. On other architectures (such as x86), the sigreturn* functions take no argument and instead use current_pt_regs() to acquire the user registers. This requires less boilerplate code, and allows for other features such as interposing C code in this path. This patch takes the same approach for arm64. Signed-off-by:
-
Mark Rutland authored
In subsequent patches, we'll want to make use of sve_user_enable() and sve_user_disable() outside of kernel/fpsimd.c. Let's move these to <asm/fpsimd.h> where we can make use of them. To avoid ifdeffery in sequences like: if (system_supports_sve() && some_condition) sve_user_disable(); ... empty stubs are provided when support for SVE is not enabled. Note that system_supports_sve() contains as IS_ENABLED(CONFIG_ARM64_SVE), so the sve_user_disable() call should be optimized away entirely when CONFIG_ARM64_SVE is not selected. To ensure that this is the case, the stub definitions contain a BUILD_BUG(), as we do for other stubs for which calls should always be optimized away when the relevant config option is not selected. At the same time, the include list of <asm/fpsimd.h> is sorted while adding <asm/sysreg.h>. Signed-off-by:
-
Mark Rutland authored
Now that we have sysreg_clear_set(), we can use this instead of change_cpacr(). Note that the order of the set and clear arguments differs between change_cpacr() and sysreg_clear_set(), so these are flipped as part of the conversion. Also, sve_user_enable() redundantly clears CPACR_EL1_ZEN_EL0EN before setting it; this is removed for clarity. Signed-off-by:
-
Mark Rutland authored
Now that we have sysreg_clear_set(), we can consistently use this instead of config_sctlr_el1(). Signed-off-by:
-
Mark Rutland authored
Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are self-consistent with an assertion in config_sctlr_el1(). This is a bit unusual, since config_sctlr_el1() doesn't make use of these definitions, and is far away from the definitions themselves. We can use the CPP #error directive to have equivalent assertions in <asm/sysreg.h>, next to the definitions of the set/clear bits, which is a bit clearer and simpler. At the same time, lets fill in the upper 32 bits for both registers in their respective RES0 definitions. This could be a little nicer with GENMASK_ULL(63, 32), but this currently lives in <linux/bitops.h>, which cannot safely be included from assembly, as <asm/sysreg.h> can. Note the when the preprocessor evaluates an expression for an #if directive, all signed or unsigned values are treated as intmax_t or uintmax_t respectively. To avoid ambiguity, we define explicitly define the mask of all 64 bits. Signed-off-by:
-
