BMC/Intel-BMC/linux.git/arch/arm64/Kconfig, branch dev-5.4

arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419

2020-04-29T14:32:56+00:00

[ Upstream commit 05460849c3b51180d5ada3373d0449aea19075e4 ] Cores affected by Neoverse-N1 #1542419 could execute a stale instruction when a branch is updated to point to freshly generated instructions. To workaround this issue we need user-space to issue unnecessary icache maintenance that we can trap. Start by hiding CTR_EL0.DIC. Reviewed-by: Suzuki K Poulose Signed-off-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: James Morse Signed-off-by: Sasha Levin

arm64: Implement copy_thread_tls

2020-01-14T19:08:34+00:00

commit a4376f2fbcc8084832f2f114577c8d68234c7903 upstream. This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras Cc: linux-arm-kernel@lists.infradead.org Cc: # 5.3.x Acked-by: Will Deacon Link: https://lore.kernel.org/r/20200102172413.654385-3-amanieu@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman

Merge branch 'errata/tx2-219' into for-next/fixes

2019-10-17T20:42:42+00:00

Workaround for Cavium/Marvell ThunderX2 erratum #219. * errata/tx2-219: arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected arm64: Avoid Cavium TX2 erratum 219 when switching TTBR arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set

arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected

2019-10-08T11:25:25+00:00

Allow the user to select the workaround for TX2-219, and update the silicon-errata.rst file to reflect this. Cc: Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon

arm64: Kconfig: Make CONFIG_COMPAT_VDSO a proper Kconfig option

2019-10-07T12:32:15+00:00

CONFIG_COMPAT_VDSO is defined by passing '-DCONFIG_COMPAT_VDSO' to the compiler when the generic compat vDSO code is in use. It's much cleaner and simpler to expose this as a proper Kconfig option (like x86 does), so do that and remove the bodge. Acked-by: Catalin Marinas Signed-off-by: Will Deacon

arm64: vdso32: Fix broken compat vDSO build warnings

2019-10-07T10:07:16+00:00

The .config file and the generated include/config/auto.conf can end up out of sync after a set of commands since CONFIG_CROSS_COMPILE_COMPAT_VDSO is not updated correctly. The sequence can be reproduced as follows: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig [...] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Which results in: arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built even though the compat vDSO has been built: $ file arch/arm64/kernel/vdso32/vdso.so arch/arm64/kernel/vdso32/vdso.so: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c67f6c786f2d2d6f86c71f708595594aa25247f6, stripped A similar case that involves changing the configuration parameter multiple times can be reconducted to the same family of problems. Remove the use of CONFIG_CROSS_COMPILE_COMPAT_VDSO altogether and instead rely on the cross-compiler prefix coming from the environment via CROSS_COMPILE_COMPAT, much like we do for the rest of the kernel. Cc: Will Deacon Cc: Catalin Marinas Reported-by: Will Deacon Signed-off-by: Vincenzo Frascino Signed-off-by: Will Deacon

Merge branch 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2019-09-28T15:14:15+00:00

Pull kernel lockdown mode from James Morris: "This is the latest iteration of the kernel lockdown patchset, from Matthew Garrett, David Howells and others. From the original description: This patchset introduces an optional kernel lockdown feature, intended to strengthen the boundary between UID 0 and the kernel. When enabled, various pieces of kernel functionality are restricted. Applications that rely on low-level access to either hardware or the kernel may cease working as a result - therefore this should not be enabled without appropriate evaluation beforehand. The majority of mainstream distributions have been carrying variants of this patchset for many years now, so there's value in providing a doesn't meet every distribution requirement, but gets us much closer to not requiring external patches. There are two major changes since this was last proposed for mainline: - Separating lockdown from EFI secure boot. Background discussion is covered here: https://lwn.net/Articles/751061/ - Implementation as an LSM, with a default stackable lockdown LSM module. This allows the lockdown feature to be policy-driven, rather than encoding an implicit policy within the mechanism. The new locked_down LSM hook is provided to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. The included lockdown LSM provides an implementation with a simple policy intended for general purpose use. This policy provides a coarse level of granularity, controllable via the kernel command line: lockdown={integrity|confidentiality} Enable the kernel lockdown feature. If set to integrity, kernel features that allow userland to modify the running kernel are disabled. If set to confidentiality, kernel features that allow userland to extract confidential information from the kernel are also disabled. This may also be controlled via /sys/kernel/security/lockdown and overriden by kernel configuration. New or existing LSMs may implement finer-grained controls of the lockdown features. Refer to the lockdown_reason documentation in include/linux/security.h for details. The lockdown feature has had signficant design feedback and review across many subsystems. This code has been in linux-next for some weeks, with a few fixes applied along the way. Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf when kernel lockdown is in confidentiality mode") is missing a Signed-off-by from its author. Matthew responded that he is providing this under category (c) of the DCO" * 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits) kexec: Fix file verification on S390 security: constify some arrays in lockdown LSM lockdown: Print current->comm in restriction messages efi: Restrict efivar_ssdt_load when the kernel is locked down tracefs: Restrict tracefs when the kernel is locked down debugfs: Restrict debugfs when the kernel is locked down kexec: Allow kexec_file() with appropriate IMA policy when locked down lockdown: Lock down perf when in confidentiality mode bpf: Restrict bpf when kernel lockdown is in confidentiality mode lockdown: Lock down tracing and perf kprobes when in confidentiality mode lockdown: Lock down /proc/kcore x86/mmiotrace: Lock down the testmmiotrace module lockdown: Lock down module params that specify hardware parameters (eg. ioport) lockdown: Lock down TIOCSSERIAL lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down acpi: Disable ACPI table override if the kernel is locked down acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down ACPI: Limit access to custom_method when the kernel is locked down x86/msr: Restrict MSR access when the kernel is locked down x86: Lock down IO port access when the kernel is locked down ...

arm64, mm: make randomization selected by generic topdown mmap layout

2019-09-24T22:54:11+00:00

This commits selects ARCH_HAS_ELF_RANDOMIZE when an arch uses the generic topdown mmap layout functions so that this security feature is on by default. Note that this commit also removes the possibility for arm64 to have elf randomization and no MMU: without MMU, the security added by randomization is worth nothing. Link: http://lkml.kernel.org/r/20190730055113.23635-6-alex@ghiti.fr Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Cc: Albert Ou Cc: Alexander Viro Cc: Christoph Hellwig Cc: James Hogan Cc: Palmer Dabbelt Cc: Paul Burton Cc: Ralf Baechle Cc: Russell King Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

arm64, mm: move generic mmap layout functions to mm

2019-09-24T22:54:11+00:00

arm64 handles top-down mmap layout in a way that can be easily reused by other architectures, so make it available in mm. It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT that can be set by other architectures to benefit from those functions. Note that this new config depends on MMU being enabled, if selected without MMU support, a warning will be thrown. Link: http://lkml.kernel.org/r/20190730055113.23635-5-alex@ghiti.fr Signed-off-by: Alexandre Ghiti Suggested-by: Christoph Hellwig Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Cc: Albert Ou Cc: Alexander Viro Cc: James Hogan Cc: Palmer Dabbelt Cc: Paul Burton Cc: Ralf Baechle Cc: Russell King Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2019-09-20T18:42:07+00:00

Pull arm64 fixes from Will Deacon: "We've had a few arm64 fixes trickle in this week. Nothing catastophic, but all things that should be addressed: - Fix clang build breakage with CONFIG_OPTIMIZE_INLINING=y - Fix compilation of pointer tagging selftest - Fix COND_SYSCALL definitions to work with CFI checks - Fix stale documentation reference in our Kconfig" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI arm64: fix function types in COND_SYSCALL selftests, arm64: add kernel headers path for tags_test arm64: fix unreachable code issue with cmpxchg