An error occurred fetching the project authors.
- 13 Sep, 2020 1 commit
-
-
Marc Zyngier authored
In order to deal with IPIs as normal interrupts, let's add a new way to register them with the architecture code. set_smp_ipi_range() takes a range of interrupts, and allows the arch code to request them as if the were normal interrupts. A standard handler is then called by the core IRQ code to deal with the IPI. This means that we don't need to call irq_enter/irq_exit, and that we don't need to deal with set_irq_regs either. So let's move the dispatcher into its own function, and leave handle_IPI() as a compatibility function. On the sending side, let's make use of ipi_send_mask, which already exists for this purpose. One of the major difference is that we end up, in some cases (such as when performing IRQ time accounting on the scheduler IPI), end up with nested irq_enter()/irq_exit() pairs. Other than the (relatively small) overhead, there should be no consequences to it (these pairs are designed to nest correctly, and the accounting shouldn't be off). Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org>
-
- 29 Jul, 2020 1 commit
-
-
Valentin Schneider authored
Qian reported that the current setup forgoes the Kconfig dependencies and results in warnings such as: WARNING: unmet direct dependencies detected for SCHED_THERMAL_PRESSURE Depends on [n]: SMP [=y] && CPU_FREQ_THERMAL [=n] Selected by [y]: - ARM64 [=y] Revert commit e17ae7fe ("arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE") and re-implement it by making the option default to 'y' for arm64 and arm, which respects Kconfig dependencies (i.e. will remain 'n' if CPU_FREQ_THERMAL=n). Fixes: e17ae7fe ("arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE") Reported-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200729135718.1871-1-valentin.schneider@arm.com
-
- 28 Jul, 2020 1 commit
-
-
David Brazdil authored
The HARDEN_EL2_VECTORS config maps vectors at a fixed location on cores which are susceptible to Spector variant 3a (A57, A72) to prevent defeating hyp layout randomization by leaking the value of VBAR_EL2. Since this feature is only applicable when EL2 layout randomization is enabled, unify both behind the same RANDOMIZE_BASE Kconfig. Majority of code remains conditional on a capability selected for the affected cores. Signed-off-by:
David Brazdil <dbrazdil@google.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200721094445.82184-3-dbrazdil@google.com
-
- 24 Jul, 2020 1 commit
-
-
Andrei Vagin authored
CONFIG_TIME_NS is dependes on GENERIC_VDSO_TIME_NS. Signed-off-by:
Andrei Vagin <avagin@gmail.com> Reviewed-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by:
Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20200624083321.144975-7-avagin@gmail.comSigned-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 22 Jul, 2020 1 commit
-
-
Valentin Schneider authored
This option now correctly depends on CPU_FREQ_THERMAL, so select it on the architectures that implement the required functions, arch_set_thermal_pressure() and arch_get_thermal_pressure(). Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Link: https://lkml.kernel.org/r/20200712165917.9168-4-valentin.schneider@arm.com
-
- 15 Jul, 2020 1 commit
-
-
Zhenyu Ye authored
TLBI RANGE feature instoduces new assembly instructions and only support by binutils >= 2.30. Add necessary Kconfig logic to allow this to be enabled and pass '-march=armv8.4-a' to KBUILD_CFLAGS. Signed-off-by:
Zhenyu Ye <yezhenyu2@huawei.com> Link: https://lore.kernel.org/r/20200715071945.897-3-yezhenyu2@huawei.comSigned-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 04 Jul, 2020 1 commit
-
-
Christian Brauner authored
All architectures support copy_thread_tls() now, so remove the legacy copy_thread() function and the HAVE_COPY_THREAD_TLS config option. Everyone uses the same process creation calling convention based on copy_thread_tls() and struct kernel_clone_args. This will make it easier to maintain the core process creation code under kernel/, simplifies the callpaths and makes the identical for all architectures. Cc: linux-arch@vger.kernel.org Acked-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by:
Greentime Hu <green.hu@gmail.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com>
-
- 02 Jul, 2020 1 commit
-
-
Mark Brown authored
We have support for emulating a number of deprecated instructions in the kernel with individual Kconfig options enabling this support per instruction. In addition to the Kconfig options we also provide runtime control via sysctls but this is not currently mentioned in the Kconfig so not very discoverable for users. This is particularly important for SWP/SWPB since this is disabled by default at runtime and must be enabled via the sysctl, causing considerable frustration for users who have enabled the config option and are then confused to find that the instruction is still faulting. Add a reference to the sysctls in the help text for each of the config options, noting that SWP/SWPB is disabled by default, to improve the user experience. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200625131507.32334-1-broonie@kernel.orgSigned-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 23 Jun, 2020 1 commit
-
-
Mark Brown authored
Versions of binutils prior to 2.33.1 don't understand the ELF notes that are added by modern compilers to indicate the PAC and BTI options used to build the code. This causes them to emit large numbers of warnings in the form: aarch64-linux-gnu-nm: warning: .tmp_vmlinux.kallsyms2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000 during the kernel build which is currently causing quite a bit of disruption for automated build testing using clang. In commit 15cd0e67 (arm64: Kconfig: ptrauth: Add binutils version check to fix mismatch) we added a dependency on binutils to avoid this issue when building with versions of GCC that emit the notes but did not do so for clang as it was believed that the existing check for .cfi_negate_ra_state was already requiring a new enough binutils. This does not appear to be the case for some versions of binutils (eg, the binutils in Debian 10) so instead refactor so we require a new enough GNU binutils in all cases other than when we are using an old GCC version that does not emit notes. Other, more exotic, combinations of tools are possible such as using clang, lld and gas together are possible and may have further problems but rather than adding further version checks it looks like the most robust thing will be to just test that we can build cleanly with the configured tools but that will require more review and discussion so do this for now to address the immediate problem disrupting build testing. Reported-by:
KernelCI <bot@kernelci.org> Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1054 Link: https://lore.kernel.org/r/20200619123550.48098-1-broonie@kernel.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
- 22 Jun, 2020 1 commit
-
-
Marc Zyngier authored
We currently prevent PtrAuth from even being built if KVM is selected, but VHE isn't. It is a bit of a pointless restriction, since we also check this at run time (rejecting the enabling of PtrAuth for the vcpu if we're not running with VHE). Just drop this apparently useless restriction. Acked-by:
Andrew Scull <ascull@google.com> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org>
-
- 17 Jun, 2020 2 commits
-
-
Will Deacon authored
Unfortunately, most versions of clang that support BTI are capable of miscompiling the kernel when converting a switch statement into a jump table. As an example, attempting to spawn a KVM guest results in a panic: [ 56.253312] Kernel panic - not syncing: bad mode [ 56.253834] CPU: 0 PID: 279 Comm: lkvm Not tainted 5.8.0-rc1 #2 [ 56.254225] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ 56.254712] Call trace: [ 56.254952] dump_backtrace+0x0/0x1d4 [ 56.255305] show_stack+0x1c/0x28 [ 56.255647] dump_stack+0xc4/0x128 [ 56.255905] panic+0x16c/0x35c [ 56.256146] bad_el0_sync+0x0/0x58 [ 56.256403] el1_sync_handler+0xb4/0xe0 [ 56.256674] el1_sync+0x7c/0x100 [ 56.256928] kvm_vm_ioctl_check_extension_generic+0x74/0x98 [ 56.257286] __arm64_sys_ioctl+0x94/0xcc [ 56.257569] el0_svc_common+0x9c/0x150 [ 56.257836] do_el0_svc+0x84/0x90 [ 56.258083] el0_sync_handler+0xf8/0x298 [ 56.258361] el0_sync+0x158/0x180 This is because the switch in kvm_vm_ioctl_check_extension_generic() is executed as an indirect branch to tail-call through a jump table: ffff800010032dc8: 3869694c ldrb w12, [x10, x9] ffff800010032dcc: 8b0c096b add x11, x11, x12, lsl #2 ffff800010032dd0: d61f0160 br x11 However, where the target case uses the stack, the landing pad is elided due to the presence of a paciasp instruction: ffff800010032e14: d503233f paciasp ffff800010032e18: a9bf7bfd stp x29, x30, [sp, #-16]! ffff800010032e1c: 910003fd mov x29, sp ffff800010032e20: aa0803e0 mov x0, x8 ffff800010032e24: 940017c0 bl ffff800010038d24 <kvm_vm_ioctl_check_extension> ffff800010032e28: 93407c00 sxtw x0, w0 ffff800010032e2c: a8c17bfd ldp x29, x30, [sp], #16 ffff800010032e30: d50323bf autiasp ffff800010032e34: d65f03c0 ret Unfortunately, this results in a fatal exception because paciasp is compatible only with branch-and-link (call) instructions and not simple indirect branches. A fix is being merged into Clang 10.0.1 so that a 'bti j' instruction is emitted as an explicit landing pad in this situation. Make in-kernel BTI depend on that compiler version when building with clang. Cc: Tom Stellard <tstellar@redhat.com> Cc: Daniel Kiss <daniel.kiss@arm.com> Reviewed-by:
Mark Brown <broonie@kernel.org> Acked-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20200615105524.GA2694@willie-the-truck Link: https://lore.kernel.org/r/20200616183630.2445-1-will@kernel.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
Masahiro Yamada authored
cc-option and as-option are almost the same; both pass the flag to $(CC). The main difference is the cc-option stops before the assemble stage (-S option) whereas as-option stops after (-c option). I chose -S because it is slightly faster, but $(cc-option,-gz=zlib) returns a wrong result (https://lkml.org/lkml/2020/6/9/1529). It has been fixed by commit 7b169944 ("Makefile: Improve compressed debug info support detection"), but the assembler should always be invoked for more reliable compiler option tests. However, you cannot simply replace -S with -c because the following code in lib/Kconfig.debug would break: depends on $(cc-option,-gsplit-dwarf) The combination of -c and -gsplit-dwarf does not accept /dev/null as output. $ cat /dev/null | gcc -gsplit-dwarf -S -x c - -o /dev/null $ echo $? 0 $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o /dev/null objcopy: Warning: '/dev/null' is not an ordinary file $ echo $? 1 $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o tmp.o $ echo $? 0 There is another flag that creates an separate file based on the object file path: $ cat /dev/null | gcc -ftest-coverage -c -x c - -o /dev/null <stdin>:1: error: cannot open /dev/null.gcno So, we cannot use /dev/null to sink the output. Align the cc-option implementation with scripts/Kbuild.include. With -c option used in cc-option, as-option is unneeded. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Will Deacon <will@kernel.org>
-
- 13 Jun, 2020 1 commit
-
-
Masahiro Yamada authored
Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- 11 Jun, 2020 1 commit
-
-
Ard Biesheuvel authored
Commit cfa7ede2 ("arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely") results in boot failures when booting kernels that are built without KASLR support on broken bootloaders that ignore the TEXT_OFFSET value passed via the header, and use the default of 0x80000 instead. To work around this, turn CONFIG_RELOCATABLE on by default, even if KASLR itself (CONFIG_RANDOMIZE_BASE) is turned off, and require CONFIG_EXPERT to be enabled to deviate from this. Then, emit a warning into the kernel log if we are not booting via the EFI stub (which is permitted to deviate from the placement restrictions) and the kernel base address is not placed according to the rules as laid out in Documentation/arm64/booting.rst. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200611124330.252163-1-ardb@kernel.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
- 10 Jun, 2020 1 commit
-
-
Nick Desaulniers authored
Allow the compat vdso (32b) to be compiled as either THUMB2 (default) or ARM. For THUMB2, the register r7 is reserved for the frame pointer, but code in arch/arm64/include/asm/vdso/compat_gettimeofday.h uses r7. Explicitly set -fomit-frame-pointer, since unwinding through interworked THUMB2 and ARM is unreliable anyways. See also how CONFIG_UNWINDER_FRAME_POINTER cannot be selected for CONFIG_THUMB2_KERNEL for ARCH=arm. This also helps toolchains that differ in their implicit value if the choice of -f{no-}omit-frame-pointer is left unspecified, to not error on the use of r7. 2019 Q4 ARM AAPCS seeks to standardize the use of r11 as the reserved frame pointer register, but no production compiler that can compile the Linux kernel currently implements this. We're actively discussing such a transition with ARM toolchain developers currently. Reported-by:
Luis Lozano <llozano@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Manoj Gupta <manojgupta@google.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Stephen Boyd <swboyd@google.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Dave Martin <Dave.Martin@arm.com> Link: https://static.docs.arm.com/ihi0042/i/aapcs32.pdf Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084372 Link: https://lore.kernel.org/r/20200608205711.109418-1-ndesaulniers@google.comSigned-off-by:
Will Deacon <will@kernel.org>
-
- 05 Jun, 2020 1 commit
-
-
Anshuman Khandual authored
This adds tests which will validate architecture page table helpers and other accessors in their compliance with expected generic MM semantics. This will help various architectures in validating changes to existing page table helpers or addition of new ones. This test covers basic page table entry transformations including but not limited to old, young, dirty, clean, write, write protect etc at various level along with populating intermediate entries with next page table page and validating them. Test page table pages are allocated from system memory with required size and alignments. The mapped pfns at page table levels are derived from a real pfn representing a valid kernel text symbol. This test gets called via late_initcall(). This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any architecture, which is willing to subscribe this test will need to select ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390 and powerpc platforms where the test is known to build and run successfully Going forward, other architectures too can subscribe the test after fixing any build or runtime problems with their page table helpers. Folks interested in making sure that a given platform's page table helpers conform to expected generic MM semantics should enable the above config which will just trigger this test during boot. Any non conformity here will be reported as an warning which would need to be fixed. This test will help catch any changes to the agreed upon semantics expected from generic MM and enable platforms to accommodate it thereafter. [anshuman.khandual@arm.com: v17] Link: http://lkml.kernel.org/r/1587436495-22033-3-git-send-email-anshuman.khandual@arm.com [anshuman.khandual@arm.com: v18] Link: http://lkml.kernel.org/r/1588564865-31160-3-git-send-email-anshuman.khandual@arm.comSuggested-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390] Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> [ppc32] Reviewed-by:
Ingo Molnar <mingo@kernel.org> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Link: http://lkml.kernel.org/r/1583919272-24178-1-git-send-email-anshuman.khandual@arm.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 04 Jun, 2020 2 commits
-
-
Zong Li authored
Extract DEBUG_WX to mm/Kconfig.debug for shared use. Change to use ARCH_HAS_DEBUG_WX instead of DEBUG_WX defined by arch port. Signed-off-by:
Zong Li <zong.li@sifive.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Link: http://lkml.kernel.org/r/e19709e7576f65e303245fe520cad5f7bae72763.1587455584.git.zong.li@sifive.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Rapoport authored
CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization of nodes and zones structures between the systems that have region to node mapping in memblock and those that don't. Currently all the NUMA architectures enable this option and for the non-NUMA systems we can presume that all the memory belongs to node 0 and therefore the compile time configuration option is not required. The remaining few architectures that use DISCONTIGMEM without NUMA are easily updated to use memblock_add_node() instead of memblock_add() and thus have proper correspondence of memblock regions to NUMA nodes. Still, free_area_init_node() must have a backward compatible version because its semantics with and without CONFIG_HAVE_MEMBLOCK_NODE_MAP is different. Once all the architectures will use the new semantics, the entire compatibility layer can be dropped. To avoid addition of extra run time memory to store node id for architectures that keep memblock but have only a single node, the node id field of the memblock_region is guarded by CONFIG_NEED_MULTIPLE_NODES and the corresponding accessors presume that in those cases it is always 0. Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by: Hoan Tran <hoan@os.amperecomputing.com> [arm64] Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64] Cc: Baoquan He <bhe@redhat.com> Cc: Brian Cain <bcain@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Guo Ren <guoren@kernel.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ley Foon Tan <ley.foon.tan@intel.com> Cc: Mark Salter <msalter@redhat.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Simek <monstr@monstr.eu> Cc: Nick Hu <nickhu@andestech.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Stafford Horne <shorne@gmail.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Link: http://lkml.kernel.org/r/20200412194859.12663-4-rppt@kernel.orgSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 15 May, 2020 2 commits
-
-
Sami Tolvanen authored
This change implements shadow stack switching, initial SCS set-up, and interrupt shadow stacks for arm64. Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Will Deacon <will@kernel.org>
-
Daniel Borkmann authored
Given the legacy bpf_probe_read{,str}() BPF helpers are broken on archs with overlapping address ranges, we should really take the next step to disable them from BPF use there. To generally fix the situation, we've recently added new helper variants bpf_probe_read_{user,kernel}() and bpf_probe_read_{user,kernel}_str(). For details on them, see 6ae08ae3 ("bpf: Add probe_read_{user, kernel} and probe_read_{user,kernel}_str helpers"). Given bpf_probe_read{,str}() have been around for ~5 years by now, there are plenty of users at least on x86 still relying on them today, so we cannot remove them entirely w/o breaking the BPF tracing ecosystem. However, their use should be restricted to archs with non-overlapping address ranges where they are working in their current form. Therefore, move this behind a CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE and have x86, arm64, arm select it (other archs supporting it can follow-up on it as well). For the remaining archs, they can workaround easily by relying on the feature probe from bpftool which spills out defines that can be used out of BPF C code to implement the drop-in replacement for old/new kernels via: bpftool feature probe macro Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Reviewed-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Brendan Gregg <brendan.d.gregg@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/bpf/20200515101118.6508-2-daniel@iogearbox.net
-
- 12 May, 2020 1 commit
-
-
Will Deacon authored
Some versions of GCC are known to suffer from a BTI code generation bug, meaning that CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI cannot be solely used to determine whether or not we can compile with kernel with BTI enabled. Update the BTI Kconfig entry to refer to the relevant GCC bugzilla entry (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697) and update the check now that the fix has been merged into GCC release 10.1. Acked-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Will Deacon <will@kernel.org>
-
- 07 May, 2020 1 commit
-
-
Mark Brown authored
Now that all the code is in place provide a Kconfig option allowing users to enable BTI for the kernel if their toolchain supports it, defaulting it on since this has security benefits. This is a separate configuration option since we currently don't support secondary CPUs that lack BTI if the boot CPU supports it. Code generation issues mean that current GCC 9 versions are not able to produce usable BTI binaries so we disable support for building with GCC versions prior to 10, once a fix is backported to GCC 9 the dependencies will be updated. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20200506195138.22086-8-broonie@kernel.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
- 05 May, 2020 1 commit
-
-
Geert Uytterhoeven authored
Sort configuration options for vendor-specific errata by vendor, to increase uniformity. Move ARM64_WORKAROUND_REPEAT_TLBI up, as it is also selected by ARM64_ERRATUM_1286807. Acked-by:
Mark Rutland <mark.rutland@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Will Deacon <will@kernel.org>
-
- 04 May, 2020 2 commits
-
-
Andrew Scull authored
Errata 1165522, 1319367 and 1530923 each allow TLB entries to be allocated as a result of a speculative AT instruction. In order to avoid mandating VHE on certain affected CPUs, apply the workaround to both the nVHE and the VHE case for all affected CPUs. Signed-off-by:
Andrew Scull <ascull@google.com> Acked-by:
Will Deacon <will@kernel.org> CC: Marc Zyngier <maz@kernel.org> CC: James Morse <james.morse@arm.com> CC: Suzuki K Poulose <suzuki.poulose@arm.com> CC: Will Deacon <will@kernel.org> CC: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20200504094858.108917-1-ascull@google.comSigned-off-by:
Will Deacon <will@kernel.org>
-
Mark Brown authored
Now that we have converted arm64 over to the new style SYM_ assembler annotations select ARCH_USE_SYM_ANNOTATIONS so the old macros aren't available and we don't regress. Signed-off-by:
Mark Brown <broonie@kernel.org> Acked-by:
Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200501115430.37315-4-broonie@kernel.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
- 23 Apr, 2020 1 commit
-
-
Atish Patra authored
Most of the arm-stub code is written in an architecture independent manner. As a result, RISC-V can reuse most of the arm-stub code. Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it. This patch doesn't introduce any functional changes. Signed-off-by:
Atish Patra <atish.patra@wdc.com> Reviewed-by:
Palmer Dabbelt <palmerdabbelt@google.com> Link: https://lore.kernel.org/r/20200415195422.19866-2-atish.patra@wdc.comSigned-off-by:
Ard Biesheuvel <ardb@kernel.org>
-
- 01 Apr, 2020 1 commit
-
-
Amit Daniel Kachhap authored
Recent addition of ARM64_PTR_AUTH exposed a mismatch issue with binutils. 9.1+ versions of gcc inserts a section note .note.gnu.property but this can be used properly by binutils version greater than 2.33.1. If older binutils are used then the following warnings are generated, aarch64-linux-ld: warning: arch/arm64/kernel/vdso/vgettimeofday.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000 aarch64-linux-objdump: warning: arch/arm64/lib/csum.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000 aarch64-linux-nm: warning: .tmp_vmlinux1: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000 This patch enables ARM64_PTR_AUTH when gcc and binutils versions are compatible with each other. Older gcc which do not insert such section continue to work as before. This scenario may not occur with clang as a recent commit 3b446c7d ("arm64: Kconfig: verify binutils support for ARM64_PTR_AUTH") masks binutils version lesser then 2.34. Reported-by:
kbuild test robot <lkp@intel.com> Suggested-by:
Vincenzo Frascino <Vincenzo.Frascino@arm.com> Signed-off-by:
Amit Daniel Kachhap <amit.kachhap@arm.com> [catalin.marinas@arm.com: slight adjustment to the comment] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 20 Mar, 2020 1 commit
-
-
Nick Desaulniers authored
Clang relies on GNU as from binutils to assemble the Linux kernel, currently. A recent patch to enable the armv8.3-a extension for pointer authentication checked for compiler support of the relevant flags. Everything works with binutils 2.34+, but for older versions we observe assembler errors: /tmp/vgettimeofday-36a54b.s: Assembler messages: /tmp/vgettimeofday-36a54b.s:40: Error: unknown pseudo-op: `.cfi_negate_ra_state' When compiling with Clang, require the assembler to support .cfi_negate_ra_state directives, in order to support CONFIG_ARM64_PTR_AUTH. Link: https://github.com/ClangBuiltLinux/linux/issues/938Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Tested-by:
Nathan Chancellor <natechancellor@gmail.com>
-
- 18 Mar, 2020 4 commits
-
-
Will Deacon authored
Commit ab7876a9 ("arm64: elf: Enable BTI at exec based on ELF program properties") introduced the conditional selection of ARCH_USE_GNU_PROPERTY if BINFMT_ELF is enabled. With allnoconfig, this option is no longer selected and the arm64 arch_parse_elf_property() function clashes with the generic dummy implementation. Link: http://lkml.kernel.org/r/20200318082830.GA31312@willie-the-truck Fixes: ab7876a9 ("arm64: elf: Enable BTI at exec based on ELF program properties") Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Kristina Martsenko authored
Compile all functions with two ptrauth instructions: PACIASP in the prologue to sign the return address, and AUTIASP in the epilogue to authenticate the return address (from the stack). If authentication fails, the return will cause an instruction abort to be taken, followed by an oops and killing the task. This should help protect the kernel against attacks using return-oriented programming. As ptrauth protects the return address, it can also serve as a replacement for CONFIG_STACKPROTECTOR, although note that it does not protect other parts of the stack. The new instructions are in the HINT encoding space, so on a system without ptrauth they execute as NOPs. CONFIG_ARM64_PTR_AUTH now not only enables ptrauth for userspace and KVM guests, but also automatically builds the kernel with ptrauth instructions if the compiler supports it. If there is no compiler support, we do not warn that the kernel was built without ptrauth instructions. GCC 7 and 8 support the -msign-return-address option, while GCC 9 deprecates that option and replaces it with -mbranch-protection. Support both options. Clang uses an external assembler hence this patch makes sure that the correct parameters (-march=armv8.3-a) are passed down to help it recognize the ptrauth instructions. Ftrace function tracer works properly with Ptrauth only when patchable-function-entry feature is present and is ensured by the Kconfig dependency. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by: Vincenzo Frascino <Vincenzo.Frascino@arm.com> # not co-dev parts Co-developed-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
Kristina Martsenko <kristina.martsenko@arm.com> [Amit: Cover leaf function, comments, Ftrace Kconfig] Signed-off-by:
Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Amit Daniel Kachhap authored
Functions like vmap() record how much memory has been allocated by their callers, and callers are identified using __builtin_return_address(). Once the kernel is using pointer-auth the return address will be signed. This means it will not match any kernel symbol, and will vary between threads even for the same caller. The output of /proc/vmallocinfo in this case may look like, 0x(____ptrval____)-0x(____ptrval____) 20480 0x86e28000100e7c60 pages=4 vmalloc N0=4 0x(____ptrval____)-0x(____ptrval____) 20480 0x86e28000100e7c60 pages=4 vmalloc N0=4 0x(____ptrval____)-0x(____ptrval____) 20480 0xc5c78000100e7c60 pages=4 vmalloc N0=4 The above three 64bit values should be the same symbol name and not different LR values. Use the pre-processor to add logic to clear the PAC to __builtin_return_address() callers. This patch adds a new file asm/compiler.h and is transitively included via include/compiler_types.h on the compiler command line so it is guaranteed to be loaded and the users of this macro will not find a wrong version. Helper macros ptrauth_kernel_pac_mask/ptrauth_clear_pac are created for this purpose and added in this file. Existing macro ptrauth_user_pac_mask moved from asm/pointer_auth.h. Signed-off-by:
Amit Daniel Kachhap <amit.kachhap@arm.com> Reviewed-by:
James Morse <james.morse@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Kristina Martsenko authored
When the kernel is compiled with pointer auth instructions, the boot CPU needs to start using address auth very early, so change the cpucap to account for this. Pointer auth must be enabled before we call C functions, because it is not possible to enter a function with pointer auth disabled and exit it with pointer auth enabled. Note, mismatches between architected and IMPDEF algorithms will still be caught by the cpufeature framework (the separate *_ARCH and *_IMP_DEF cpucaps). Note the change in behavior: if the boot CPU has address auth and a late CPU does not, then the late CPU is parked by the cpufeature framework. This is possible as kernel will only have NOP space intructions for PAC so such mismatched late cpu will silently ignore those instructions in C functions. Also, if the boot CPU does not have address auth and the late CPU has then the late cpu will still boot but with ptrauth feature disabled. Leave generic authentication as a "system scope" cpucap for now, since initially the kernel will only use address authentication. Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by:
Vincenzo Frascino <Vincenzo.Frascino@arm.com> Signed-off-by:
Kristina Martsenko <kristina.martsenko@arm.com> [Amit: Re-worked ptrauth setup logic, comments] Signed-off-by:
Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 16 Mar, 2020 2 commits
-
-
Dave Martin authored
Now that the code for userspace BTI support is in the kernel add the Kconfig entry so that it can be built and used. [Split out of "arm64: Basic Branch Target Identification support" -- broonie] Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Dave Martin authored
For BTI protection to be as comprehensive as possible, it is desirable to have BTI enabled from process startup. If this is not done, the process must use mprotect() to enable BTI for each of its executable mappings, but this is painful to do in the libc startup code. It's simpler and more sound to have the kernel do it instead. To this end, detect BTI support in the executable (or ELF interpreter, as appropriate), via the NT_GNU_PROGRAM_PROPERTY_TYPE_0 note, and tweak the initial prot flags for the process' executable pages to include PROT_BTI as appropriate. Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 06 Mar, 2020 1 commit
-
-
Ionela Voinescu authored
The activity monitors extension is an optional extension introduced by the ARMv8.4 CPU architecture. This implements basic support for version 1 of the activity monitors architecture, AMUv1. This support includes: - Extension detection on each CPU (boot, secondary, hotplugged) - Register interface for AMU aarch64 registers Signed-off-by:
Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 04 Mar, 2020 1 commit
-
-
Anshuman Khandual authored
The arch code for hot-remove must tear down portions of the linear map and vmemmap corresponding to memory being removed. In both cases the page tables mapping these regions must be freed, and when sparse vmemmap is in use the memory backing the vmemmap must also be freed. This patch adds unmap_hotplug_range() and free_empty_tables() helpers which can be used to tear down either region and calls it from vmemmap_free() and ___remove_pgd_mapping(). The free_mapped argument determines whether the backing memory will be freed. It makes two distinct passes over the kernel page table. In the first pass with unmap_hotplug_range() it unmaps, invalidates applicable TLB cache and frees backing memory if required (vmemmap) for each mapped leaf entry. In the second pass with free_empty_tables() it looks for empty page table sections whose page table page can be unmapped, TLB invalidated and freed. While freeing intermediate level page table pages bail out if any of its entries are still valid. This can happen for partially filled kernel page table either from a previously attempted failed memory hot add or while removing an address range which does not span the entire page table page range. The vmemmap region may share levels of table with the vmalloc region. There can be conflicts between hot remove freeing page table pages with a concurrent vmalloc() walking the kernel page table. This conflict can not just be solved by taking the init_mm ptl because of existing locking scheme in vmalloc(). So free_empty_tables() implements a floor and ceiling method which is borrowed from user page table tear with free_pgd_range() which skips freeing page table pages if intermediate address range is not aligned or maximum floor-ceiling might not own the entire page table page. Boot memory on arm64 cannot be removed. Hence this registers a new memory hotplug notifier which prevents boot memory offlining and it's removal. While here update arch_add_memory() to handle __add_pages() failures by just unmapping recently added kernel linear mapping. Now enable memory hot remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE. This implementation is overall inspired from kernel page table tear down procedure on X86 architecture and user page table tear down method. [Mike and Catalin added P4D page table level support] Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 27 Feb, 2020 1 commit
-
-
Randy Dunlap authored
Fix typos in arch/arm64/Kconfig: - spell Numa as NUMA - add hyphenation to Non-Uniform Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 20 Feb, 2020 1 commit
-
-
Frederic Weisbecker authored
The syscall slow path is spuriously invoked when context tracking is activated while the entry code calls context tracking from fast path. Remove that overhead and the unused flag itself while at it. Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org>
-
- 17 Feb, 2020 2 commits
-
-
Thomas Gleixner authored
Now that all architectures are converted to use the generic storage the helpers and conditionals can be removed. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lkml.kernel.org/r/20200207124403.470699892@linutronix.de
-
Thomas Gleixner authored
Convert ARM/ARM64 to the generic VDSO clock mode storage. This needs to happen in one go as they share the clocksource driver. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lkml.kernel.org/r/20200207124403.363235229@linutronix.de
-