# git rev-parse -q --verify aefcf2f4b58155d27340ba5f9ddbe9513da8286d^{commit} aefcf2f4b58155d27340ba5f9ddbe9513da8286d already have revision, skipping fetch # git checkout -q -f -B kisskb aefcf2f4b58155d27340ba5f9ddbe9513da8286d # git clean -qxdf # < git log -1 # commit aefcf2f4b58155d27340ba5f9ddbe9513da8286d # Merge: f1f2f614d535 45893a0abee6 # Author: Linus Torvalds # Date: Sat Sep 28 08:14:15 2019 -0700 # # Merge branch 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security # # 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 # ... # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld --version # < git log --format=%s --max-count=1 aefcf2f4b58155d27340ba5f9ddbe9513da8286d # < make -s -j 48 ARCH=powerpc O=/kisskb/build/linus_ppc64le_defconfig_ppc64le-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ppc64le_defconfig # make -s -j 48 ARCH=powerpc O=/kisskb/build/linus_ppc64le_defconfig_ppc64le-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- In file included from /kisskb/src/include/linux/list.h:9:0, from /kisskb/src/include/linux/wait.h:7, from /kisskb/src/include/linux/wait_bit.h:8, from /kisskb/src/include/linux/fs.h:6, from /kisskb/src/fs/btrfs/send.c:7: /kisskb/src/fs/btrfs/send.c: In function 'process_extent': /kisskb/src/include/linux/kernel.h:37:33: warning: 'clone_src_i_size' may be used uninitialized in this function [-Wmaybe-uninitialized] #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0) ^ /kisskb/src/fs/btrfs/send.c:5088:6: note: 'clone_src_i_size' was declared here u64 clone_src_i_size; ^ WARNING: vmlinux.o(.text+0x31e4): Section mismatch in reference from the variable __boot_from_prom to the function .init.text:prom_init() The function __boot_from_prom() references the function __init prom_init(). This is often because __boot_from_prom lacks a __init annotation or the annotation of prom_init is wrong. WARNING: vmlinux.o(.text+0x33c8): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel() The function start_here_common() references the function __init start_kernel(). This is often because start_here_common lacks a __init annotation or the annotation of start_kernel is wrong. Completed OK # rm -rf /kisskb/build/linus_ppc64le_defconfig_ppc64le-gcc5 # Build took: 0:02:43.874582