Hello,
Richard suggested I just post this here in advance of the meeting. Mix
of merge commits from Linus and the commits proper. Of course, let me
know if this is not of any interest to you. Thinking mainly of Ben and
Richard, but if there's anybody else here, sound off. These items don't
always naturally come into conversation at the dinner table during
meetings, when we kvetch about work or other.
I'd add Richard and Ben to the To:, but I don't know if metoo is turned
off in Mailman. Is it?
More of these on my work laptop. Many of them somewhat relevant at work
too.
Cheers,
Alex
commit 45824fc0da6e46cc5d563105e1eaaf3098a686f9 (HEAD -> mainline, origin/master, origin/HEAD)
Merge: 8c2b418c3f95 d9101bfa6adc
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Fri Sep 20 11:48:06 2019 -0700
Merge tag 'powerpc-5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc updates from Michael Ellerman:
"This is a bit late, partly due to me travelling, and partly due to a
power outage knocking out some of my test systems *while* I was
travelling.
Cool story.
- Support for building the kernel to run as a "Secure Virtual
Machine", ie. as a guest capable of running on a system with an
Ultravisor.
[…]
(In UT2K4 voice) supervisor, hypervisor, ultravisor!
commit 3207598ab00e0fb06c8d73c9ae567afa4847e70e
Merge: b08918fb3f27 d8a050f5a3e8
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Fri Sep 20 10:31:19 2019 -0700
Merge tag 'kgdb-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux
Pull kgdb updates from Daniel Thompson:
"It has been a quiet dev cycle for kgdb. There has been some good stuff
for kdb on the mailing list but unfortunately the patches caused a
couple of problems with the kdb pager so I had to drop those and they
will have to wait for next time!
Yes, UNIX people appreciate pagers more than you imagine… too bad I don't have
the patch to look at handy.
commit c3367a1b47d590f97109cd4b5189e750fb26c0f1
Author: Steven J. Magnani <steve [ dot ] magnani [ at ] digidescorp [ dot ] com>
Date: Tue Aug 27 07:13:59 2019 -0500
udf: augment UDF permissions on new inodes
Windows presents files created within Linux as read-only, even when
permissions in Linux indicate the file should be writable.
UDF defines a slightly different set of basic file permissions than Linux.
Specifically, UDF has "delete" and "change attribute" permissions for each
access class (user/group/other). Linux has no equivalents for these.
When the Linux UDF driver creates a file (or directory), no UDF delete or
change attribute permissions are granted. The lack of delete permission
appears to cause Windows to mark an item read-only when its permissions
otherwise indicate that it should be read-write.
Fix this by having UDF delete permissions track Linux write permissions.
Also grant UDF change attribute permission to the owner when creating a
new inode.
Reported by: Ty Young
Signed-off-by: Steven J. Magnani <steve [ at ] digidescorp [ dot ] com>
Link: https://lore.kernel.org/r/20190827121359 [ dot ] 9954-1-steve [ at ] digidescorp [ dot ] com
Signed-off-by: Jan Kara <jack [ at ] suse [ dot ] cz>
commit ab9a3a737284b3d9e1d2ba43a0ef31b3ef2e2417
Author: Steven J. Magnani <steve [ dot ] magnani [ at ] digidescorp [ dot ] com>
Date: Wed Aug 14 07:50:02 2019 -0500
udf: reduce leakage of blocks related to named streams
Windows is capable of creating UDF files having named streams.
One example is the "Zone.Identifier" stream attached automatically
to files downloaded from a network. See:
https://msdn.microsoft.com/en-us/library/dn392609.aspx
Modification of a file having one or more named streams in Linux causes
the stream directory to become detached from the file, essentially leaking
all blocks pertaining to the file's streams.
Fix by saving off information about an inode's streams when reading it,
for later use when its on-disk data is updated.
Link: https://lore.kernel.org/r/20190814125002 [ dot ] 10869-1-steve [ at ] digidescorp [ dot ] com
Signed-off-by: Steven J. Magnani <steve [ at ] digidescorp [ dot ] com>
Signed-off-by: Jan Kara <jack [ at ] suse [ dot ] cz>
commit 6fbacb8539a6659d446a9efabb538cfc007c1427
Author: Steven J. Magnani <steve [ dot ] magnani [ at ] digidescorp [ dot ] com>
Date: Thu Jul 11 08:38:52 2019 -0500
udf: support 2048-byte spacing of VRS descriptors on 4K media
Some UDF creators (specifically Microsoft, but perhaps others) mishandle
the ECMA-167 corner case that requires descriptors within a Volume
Recognition Sequence to be placed at 4096-byte intervals on media where
the block size is 4K. Instead, the descriptors are placed at the 2048-
byte interval mandated for media with smaller blocks. This nonconformity
currently prevents Linux from recognizing the filesystem as UDF.
Modify the driver to tolerate a misformatted VRS on 4K media.
[JK: Simplified descriptor checking]
Signed-off-by: Steven J. Magnani <steve [ at ] digidescorp [ dot ] com>
Tested-by: Steven J. Magnani <steve [ at ] digidescorp [ dot ] com>
Link: https://lore.kernel.org/r/20190711133852 [ dot ] 16887-2-steve [ at ] digidescorp [ dot ] com
Signed-off-by: Jan Kara <jack [ at ] suse [ dot ] cz>
Interesting MS. This has gone on for a while, but how many people still care
about UDF in this age of Netflix?
commit 70cb0d02b58128db07fc39b5e87a2873e2c16bde
Merge: 104c0d6bc43e 040823b5372b
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sat Sep 21 13:37:39 2019 -0700
Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 updates from Ted Ts'o:
"Added new ext4 debugging ioctls to allow userspace to get information
about the state of the extent status cache.
Dropped workaround for pre-1970 dates which were encoded incorrectly
in pre-4.4 kernels. Since both the kernel correctly generates, and
e2fsck detects and fixes this issue for the past four years, it'e time
to drop the workaround. (Also, it's not like files with dates in the
distant past were all that common in the first place.)
I wonder if anybody got bitten by the above.
More specific commit:
commit cd2d99229dc96219547e6349841e1aad851c6acc
Author: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Date: Mon Aug 12 13:44:49 2019 -0400
ext4: drop legacy pre-1970 encoding workaround
Originally, support for expanded timestamps had a bug in that pre-1970
times were erroneously encoded as being in the the 24th century. This
was fixed in commit a4dad1ae24f8 ("ext4: Fix handling of extended
tv_sec") which landed in 4.4. Starting with 4.4, pre-1970 timestamps
were correctly encoded, but for backwards compatibility those
incorrectly encoded timestamps were mapped back to the pre-1970 dates.
Given that backwards compatibility workaround has been around for 4
years, and given that running e2fsck from e2fsprogs 1.43.2 and later
will offer to fix these timestamps (which has been released for 3
years), it's past time to drop the legacy workaround from the kernel.
Signed-off-by: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
commit 6456ca6520ab6c9aec589b4640169cd6da378c68
Author: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Date: Tue Sep 3 01:43:17 2019 -0400
ext4: fix kernel oops caused by spurious casefold flag
If an directory has the a casefold flag set without the casefold
feature set, s_encoding will not be initialized, and this will cause
the kernel to dereference a NULL pointer. In addition to adding
checks to avoid these kernel oops, attempts to load inodes with the
casefold flag when the casefold feature is not enable will cause the
file system to be declared corrupted.
Signed-off-by: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Lovely.
commit 7727ae52975d4f4ef7ff69ed8e6e25f6a4168158
Author: zhangyi (F) <yi [ dot ] zhang [ at ] huawei [ dot ] com>
Date: Wed Aug 28 11:13:24 2019 -0400
ext4: fix potential use after free after remounting with noblock_validity
Remount process will release system zone which was allocated before if
"noblock_validity" is specified. If we mount an ext4 file system to two
mountpoints with default mount options, and then remount one of them
with "noblock_validity", it may trigger a use after free problem when
someone accessing the other one.
# mount /dev/sda foo
# mount /dev/sda bar
User access mountpoint "foo" | Remount mountpoint "bar"
|
ext4_map_blocks() | ext4_remount()
check_block_validity() | ext4_setup_system_zone()
ext4_data_block_valid() | ext4_release_system_zone()
| free system_blks rb nodes
access system_blks rb nodes |
trigger use after free |
This problem can also be reproduced by one mountpint, At the same time,
add_system_zone() can get called during remount as well so there can be
racing ext4_data_block_valid() reading the rbtree at the same time.
This patch add RCU to protect system zone from releasing or building
when doing a remount which inverse current "noblock_validity" mount
option. It assign the rbtree after the whole tree was complete and
do actual freeing after rcu grace period, avoid any intermediate state.
Reported-by: syzbot+1e470567330b7ad711d5 [ at ] syzkaller [ dot ] appspotmail [ dot ] com
Signed-off-by: zhangyi (F) <yi [ dot ] zhang [ at ] huawei [ dot ] com>
Signed-off-by: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Reviewed-by: Jan Kara <jack [ at ] suse [ dot ] cz>
Valid, but intereeeeeeeeeeesting use case you got there buddy.
commit c1e8220bd316d8ae8e524df39534b8a412a45d5e
Author: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Date: Fri Aug 23 22:38:00 2019 -0400
ext4: fix punch hole for inline_data file systems
If a program attempts to punch a hole on an inline data file, we need
to convert it to a normal file first.
This was detected using ext4/032 using the adv configuration. Simple
reproducer:
mke2fs -Fq -t ext4 -O inline_data /dev/vdc
mount /vdc
echo "" > /vdc/testfile
xfs_io -c 'truncate 33554432' /vdc/testfile
xfs_io -c 'fpunch 0 1048576' /vdc/testfile
umount /vdc
e2fsck -fy /dev/vdc
Cc: stable [ at ] vger [ dot ] kernel [ dot ] org
Signed-off-by: Theodore Ts'o <tytso [ at ] mit [ dot ] edu>
Yay! More ext4 hole punching bugs! In the same merge window that found some XFS
ones! Reminds me of a year or two ago.
commit 9dca3432ee063b70a4cfb3f0857d0aeef7b84fa8
Merge: 4553d469d6f8 73625ed66389
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sat Sep 21 11:07:02 2019 -0700
Merge tag 'for-linus-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
Pull UML updates from Richard Weinberger:
- virtio support
- fixes for our new time travel mode
UML has virtio… finally! And SCSI has virtio request batching… if you even used
that with QEMU.
commit 10fd71780f7d155f4e35fecfad0ebd4a725a244b
Merge: 3e414b5bd28f e74006edd0d4
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sat Sep 21 10:50:15 2019 -0700
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI updates from James Bottomley:
"This is mostly update of the usual drivers: qla2xxx, ufs, smartpqi,
lpfc, hisi_sas, qedf, mpt3sas; plus a whole load of minor updates. The
only core change this time around is the addition of request batching
for virtio. Since batching requires an additional flag to use, it
should be invisible to the rest of the drivers"
commit 3e414b5bd28f965fb39b9e9419d877df0cf3111a
Merge: 018c6837f3e6 afa179eb6038
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sat Sep 21 10:40:37 2019 -0700
Merge tag 'for-5.4/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper updates from Mike Snitzer:
- crypto and DM crypt advances that allow the crypto API to reclaim
implementation details that do not belong in DM crypt. The wrapper
template for ESSIV generation that was factored out will also be used
by fscrypt in the future.
- Add root hash pkcs#7 signature verification to the DM verity target.
- Add a new "clone" DM target that allows for efficient remote
replication of a device.
- Enhance DM bufio's cache to be tailored to each client based on use.
Clients that make heavy use of the cache get more of it, and those
that use less have reduced cache usage.
- Add a new DM_GET_TARGET_VERSION ioctl to allow userspace to query the
version number of a DM target (even if the associated module isn't
yet loaded).
commit 227c3e9eb5cf3552c2cc83225df6d14adb05f8e8
Merge: 56c631f5aec3 32ee8230b2b0
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sat Sep 21 09:47:19 2019 -0700
Merge tag 'compiler-attributes-for-linus-v5.4' of git://github.com/ojeda/linux
Pull asm inline support from Miguel Ojeda:
"Make use of gcc 9's "asm inline()" (Rasmus Villemoes):
gcc 9+ (and gcc 8.3, 7.5) provides a way to override the otherwise
crude heuristic that gcc uses to estimate the size of the code
represented by an asm() statement. From the gcc docs
If you use 'asm inline' instead of just 'asm', then for inlining
purposes the size of the asm is taken as the minimum size, ignoring
how many instructions GCC thinks it is.
For compatibility with older compilers, we obviously want a
#if [understands asm inline]
#define asm_inline asm inline
#else
#define asm_inline asm
#endif
But since we #define the identifier inline to attach some attributes,
we have to use an alternate spelling of that keyword. gcc provides
both __inline__ and __inline, and we currently #define both to inline,
so they all have the same semantics.
We have to free up one of __inline__ and __inline, and the latter is
by far the easiest.
The two x86 changes cause smaller code gen differences than I'd
expect, but I think we do want the asm_inline thing available sooner
or later, so this is just to get the ball rolling"
* tag 'compiler-attributes-for-linus-v5.4' of git://github.com/ojeda/linux:
x86: bug.h: use asm_inline in _BUG_FLAGS definitions
x86: alternative.h: use asm_inline for all alternative variants
compiler-types.h: add asm_inline definition
compiler_types.h: don't #define __inline
lib/zstd/mem.h: replace __inline by inline
staging: rtl8723bs: replace __inline by inline
GCC strikes back.
commit e0703556644a531e50b5dc61b9f6ea83af5f6604
Merge: 8808cf8cbc4d 2e6fcfeb9df6
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
Date: Sun Sep 22 10:34:46 2019 -0700
Merge tag 'modules-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux
Pull modules updates from Jessica Yu:
"The main bulk of this pull request introduces a new exported symbol
namespaces feature. The number of exported symbols is increasingly
growing with each release (we're at about 31k exports as of 5.3-rc7)
and we currently have no way of visualizing how these symbols are
"clustered" or making sense of this huge export surface.
Namespacing exported symbols allows kernel developers to more
explicitly partition and categorize exported symbols, as well as more
easily limiting the availability of namespaced symbols to other parts
of the kernel. For starters, we have introduced the USB_STORAGE
namespace to demonstrate the API's usage. I have briefly summarized
the feature and its main motivations in the tag below.
Summary:
- Introduce exported symbol namespaces.
This new feature allows subsystem maintainers to partition and
categorize their exported symbols into explicit namespaces. Module
authors are now required to import the namespaces they need.
Some of the main motivations of this feature include: allowing
kernel developers to better manage the export surface, allow
subsystem maintainers to explicitly state that usage of some
exported symbols should only be limited to certain users (think:
inter-module or inter-driver symbols, debugging symbols, etc), as
well as more easily limiting the availability of namespaced symbols
to other parts of the kernel.
With the module import requirement, it is also easier to spot the
misuse of exported symbols during patch review.
Two new macros are introduced: EXPORT_SYMBOL_NS() and
EXPORT_SYMBOL_NS_GPL(). The API is thoroughly documented in
Documentation/kbuild/namespaces.rst.
- Some small code and kbuild cleanups here and there"
commit 1d082773ff30e97c8bc10b65c4aa0d073664caac
Author: Matthias Maennich <maennich [ at ] google [ dot ] com>
Date: Fri Sep 6 11:32:31 2019 +0100
modpost: add support for generating namespace dependencies
This patch adds an option to modpost to generate a <module>.ns_deps file
per module, containing the namespace dependencies for that module.
E.g. if the linked module my-module.ko would depend on the symbol
myfunc.MY_NS in the namespace MY_NS, the my-module.ns_deps file created
by modpost would contain the entry MY_NS to express the namespace
dependency of my-module imposed by using the symbol myfunc.
These files can subsequently be used by static analysis tools (like
coccinelle scripts) to address issues with missing namespace imports. A
later patch of this series will introduce such a script 'nsdeps' and a
corresponding make target to automatically add missing
MODULE_IMPORT_NS() definitions to the module's sources. For that it uses
the information provided in the generated .ns_deps files.
Co-developed-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Signed-off-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Reviewed-by: Greg Kroah-Hartman <gregkh [ at ] linuxfoundation [ dot ] org>
Signed-off-by: Matthias Maennich <maennich [ at ] google [ dot ] com>
Signed-off-by: Jessica Yu <jeyu [ at ] kernel [ dot ] org>
commit cb9b55d21fe06ca5e4ba244bb5aac0afeb745c8e
Author: Matthias Maennich <maennich [ at ] google [ dot ] com>
Date: Fri Sep 6 11:32:28 2019 +0100
modpost: add support for symbol namespaces
Add support for symbols that are exported into namespaces. For that,
extract any namespace suffix from the symbol name. In addition, emit a
warning whenever a module refers to an exported symbol without
explicitly importing the namespace that it is defined in. This patch
consistently adds the namespace suffix to symbol names exported into
Module.symvers.
Example warning emitted by modpost in case of the above violation:
WARNING: module ums-usbat uses symbol usb_stor_resume from namespace
USB_STORAGE, but does not import it.
Co-developed-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Signed-off-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Reviewed-by: Joel Fernandes (Google) <joel [ at ] joelfernandes [ dot ] org>
Reviewed-by: Greg Kroah-Hartman <gregkh [ at ] linuxfoundation [ dot ] org>
Signed-off-by: Matthias Maennich <maennich [ at ] google [ dot ] com>
Signed-off-by: Jessica Yu <jeyu [ at ] kernel [ dot ] org>
commit 8651ec01daedad26290f76beeb4736f9d2da4b87
Author: Matthias Maennich <maennich [ at ] google [ dot ] com>
Date: Fri Sep 6 11:32:27 2019 +0100
module: add support for symbol namespaces.
The EXPORT_SYMBOL_NS() and EXPORT_SYMBOL_NS_GPL() macros can be used to
export a symbol to a specific namespace. There are no _GPL_FUTURE and
_UNUSED variants because these are currently unused, and I'm not sure
they are necessary.
I didn't add EXPORT_SYMBOL_NS() for ASM exports; this patch sets the
namespace of ASM exports to NULL by default. In case of relative
references, it will be relocatable to NULL. If there's a need, this
should be pretty easy to add.
A module that wants to use a symbol exported to a namespace must add a
MODULE_IMPORT_NS() statement to their module code; otherwise, modpost
will complain when building the module, and the kernel module loader
will emit an error and fail when loading the module.
MODULE_IMPORT_NS() adds a modinfo tag 'import_ns' to the module. That
tag can be observed by the modinfo command, modpost and kernel/module.c
at the time of loading the module.
The ELF symbols are renamed to include the namespace with an asm label;
for example, symbol 'usb_stor_suspend' in namespace USB_STORAGE becomes
'usb_stor_suspend.USB_STORAGE'. This allows modpost to do namespace
checking, without having to go through all the effort of parsing ELF and
relocation records just to get to the struct kernel_symbols.
On x86_64 I saw no difference in binary size (compression), but at
runtime this will require a word of memory per export to hold the
namespace. An alternative could be to store namespaced symbols in their
own section and use a separate 'struct namespaced_kernel_symbol' for
that section, at the cost of making the module loader more complex.
Co-developed-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Signed-off-by: Martijn Coenen <maco [ at ] android [ dot ] com>
Reviewed-by: Greg Kroah-Hartman <gregkh [ at ] linuxfoundation [ dot ] org>
Signed-off-by: Matthias Maennich <maennich [ at ] google [ dot ] com>
Signed-off-by: Jessica Yu <jeyu [ at ] kernel [ dot ] org>
commit c5e4a062fe661806ab291a7576dc4a41613adb86
Author: Matthias Maennich <maennich [ at ] google [ dot ] com>
Date: Fri Sep 6 11:32:25 2019 +0100
module: support reading multiple values per modinfo tag
Similar to modpost's get_next_modinfo(), introduce get_next_modinfo() in
kernel/module.c to acquire any further values associated with the same
modinfo tag name. That is useful for any tags that have multiple
occurrences (such as 'alias'), but is in particular introduced here as
part of the symbol namespaces patch series to read the (potentially)
multiple namespaces a module is importing.
commit aefcf2f4b58155d27340ba5f9ddbe9513da8286d
Merge: f1f2f614d535 45893a0abee6
Author: Linus Torvalds <torvalds [ at ] linux-foundation [ dot ] org>
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
...