linux/security/loadpin/Kconfig

42 lines
1.6 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
config SECURITY_LOADPIN
bool "Pin load of kernel files (modules, fw, etc) to one filesystem"
depends on SECURITY && BLOCK
help
Any files read through the kernel file reading interface
(kernel modules, firmware, kexec images, security policy)
can be pinned to the first filesystem used for loading. When
enabled, any files that come from other filesystems will be
rejected. This is best used on systems without an initrd that
have a root filesystem backed by a read-only device such as
dm-verity or a CDROM.
config SECURITY_LOADPIN_ENFORCE
bool "Enforce LoadPin at boot"
depends on SECURITY_LOADPIN
help
If selected, LoadPin will enforce pinning at boot. If not
selected, it can be enabled at boot with the kernel parameter
"loadpin.enforce=1".
LoadPin: Enable loading from trusted dm-verity devices Extend LoadPin to allow loading of kernel files from trusted dm-verity [1] devices. This change adds the concept of trusted verity devices to LoadPin. LoadPin maintains a list of root digests of verity devices it considers trusted. Userspace can populate this list through an ioctl on the new LoadPin securityfs entry 'dm-verity'. The ioctl receives a file descriptor of a file with verity digests as parameter. Verity reads the digests from this file after confirming that the file is located on the pinned root. The digest file must contain one digest per line. The list of trusted digests can only be set up once, which is typically done at boot time. When a kernel file is read LoadPin first checks (as usual) whether the file is located on the pinned root, if so the file can be loaded. Otherwise, if the verity extension is enabled, LoadPin determines whether the file is located on a verity backed device and whether the root digest of that device is in the list of trusted digests. The file can be loaded if the verity device has a trusted root digest. Background: As of now LoadPin restricts loading of kernel files to a single pinned filesystem, typically the rootfs. This works for many systems, however it can result in a bloated rootfs (and OTA updates) on platforms where multiple boards with different hardware configurations use the same rootfs image. Especially when 'optional' files are large it may be preferable to download/install them only when they are actually needed by a given board. Chrome OS uses Downloadable Content (DLC) [2] to deploy certain 'packages' at runtime. As an example a DLC package could contain firmware for a peripheral that is not present on all boards. DLCs use dm-verity to verify the integrity of the DLC content. [1] https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html [2] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/dlcservice/docs/developer.md Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/lkml/20220627083512.v7.2.I01c67af41d2f6525c6d023101671d7339a9bc8b5@changeid Signed-off-by: Kees Cook <keescook@chromium.org>
2022-06-27 23:35:25 +08:00
config SECURITY_LOADPIN_VERITY
bool "Allow reading files from certain other filesystems that use dm-verity"
depends on SECURITY_LOADPIN && DM_VERITY=y && SECURITYFS
help
If selected LoadPin can allow reading files from filesystems
that use dm-verity. LoadPin maintains a list of verity root
digests it considers trusted. A verity backed filesystem is
considered trusted if its root digest is found in the list
of trusted digests.
The list of trusted verity can be populated through an ioctl
on the LoadPin securityfs entry 'dm-verity'. The ioctl
expects a file descriptor of a file with verity digests as
parameter. The file must be located on the pinned root and
start with the line:
# LOADPIN_TRUSTED_VERITY_ROOT_DIGESTS
This is followed by the verity digests, with one digest per
line.