WSL2-Linux-Kernel/security/loadpin/loadpin.c

430 строки
10 KiB
C
Исходник Обычный вид История

// SPDX-License-Identifier: GPL-2.0-only
/*
* Module and Firmware Pinning Security Module
*
* Copyright 2011-2016 Google Inc.
*
* Author: Kees Cook <keescook@chromium.org>
*/
#define pr_fmt(fmt) "LoadPin: " fmt
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/kernel_read_file.h>
#include <linux/lsm_hooks.h>
#include <linux/mount.h>
#include <linux/blkdev.h>
#include <linux/path.h>
#include <linux/sched.h> /* current */
#include <linux/string_helpers.h>
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 18:35:25 +03:00
#include <linux/dm-verity-loadpin.h>
#include <uapi/linux/loadpin.h>
#define VERITY_DIGEST_FILE_HEADER "# LOADPIN_TRUSTED_VERITY_ROOT_DIGESTS"
static void report_load(const char *origin, struct file *file, char *operation)
{
char *cmdline, *pathname;
pathname = kstrdup_quotable_file(file, GFP_KERNEL);
cmdline = kstrdup_quotable_cmdline(current, GFP_KERNEL);
pr_notice("%s %s obj=%s%s%s pid=%d cmdline=%s%s%s\n",
origin, operation,
(pathname && pathname[0] != '<') ? "\"" : "",
pathname,
(pathname && pathname[0] != '<') ? "\"" : "",
task_pid_nr(current),
cmdline ? "\"" : "", cmdline, cmdline ? "\"" : "");
kfree(cmdline);
kfree(pathname);
}
static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
static char *exclude_read_files[READING_MAX_ID];
static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
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 18:35:25 +03:00
#ifdef CONFIG_SECURITY_LOADPIN_VERITY
static bool deny_reading_verity_digests;
#endif
#ifdef CONFIG_SYSCTL
static struct ctl_path loadpin_sysctl_path[] = {
{ .procname = "kernel", },
{ .procname = "loadpin", },
{ }
};
static struct ctl_table loadpin_sysctl_table[] = {
{
.procname = "enforce",
.data = &enforce,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
proc/sysctl: add shared variables for range check In the sysctl code the proc_dointvec_minmax() function is often used to validate the user supplied value between an allowed range. This function uses the extra1 and extra2 members from struct ctl_table as minimum and maximum allowed value. On sysctl handler declaration, in every source file there are some readonly variables containing just an integer which address is assigned to the extra1 and extra2 members, so the sysctl range is enforced. The special values 0, 1 and INT_MAX are very often used as range boundary, leading duplication of variables like zero=0, one=1, int_max=INT_MAX in different source files: $ git grep -E '\.extra[12].*&(zero|one|int_max)' |wc -l 248 Add a const int array containing the most commonly used values, some macros to refer more easily to the correct array member, and use them instead of creating a local one for every object file. This is the bloat-o-meter output comparing the old and new binary compiled with the default Fedora config: # scripts/bloat-o-meter -d vmlinux.o.old vmlinux.o add/remove: 2/2 grow/shrink: 0/2 up/down: 24/-188 (-164) Data old new delta sysctl_vals - 12 +12 __kstrtab_sysctl_vals - 12 +12 max 14 10 -4 int_max 16 - -16 one 68 - -68 zero 128 28 -100 Total: Before=20583249, After=20583085, chg -0.00% [mcroce@redhat.com: tipc: remove two unused variables] Link: http://lkml.kernel.org/r/20190530091952.4108-1-mcroce@redhat.com [akpm@linux-foundation.org: fix net/ipv6/sysctl_net_ipv6.c] [arnd@arndb.de: proc/sysctl: make firmware loader table conditional] Link: http://lkml.kernel.org/r/20190617130014.1713870-1-arnd@arndb.de [akpm@linux-foundation.org: fix fs/eventpoll.c] Link: http://lkml.kernel.org/r/20190430180111.10688-1-mcroce@redhat.com Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Aaron Tomlin <atomlin@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-19 01:58:50 +03:00
.extra1 = SYSCTL_ZERO,
.extra2 = SYSCTL_ONE,
},
{ }
};
/*
* This must be called after early kernel init, since then the rootdev
* is available.
*/
static void check_pinning_enforcement(struct super_block *mnt_sb)
{
bool ro = false;
/*
* If load pinning is not enforced via a read-only block
* device, allow sysctl to change modes for testing.
*/
if (mnt_sb->s_bdev) {
ro = bdev_read_only(mnt_sb->s_bdev);
pr_info("%pg (%u:%u): %s\n", mnt_sb->s_bdev,
MAJOR(mnt_sb->s_bdev->bd_dev),
MINOR(mnt_sb->s_bdev->bd_dev),
ro ? "read-only" : "writable");
} else
pr_info("mnt_sb lacks block device, treating as: writable\n");
if (!ro) {
if (!register_sysctl_paths(loadpin_sysctl_path,
loadpin_sysctl_table))
pr_notice("sysctl registration failed!\n");
else
pr_info("enforcement can be disabled.\n");
} else
pr_info("load pinning engaged.\n");
}
#else
static void check_pinning_enforcement(struct super_block *mnt_sb)
{
pr_info("load pinning engaged.\n");
}
#endif
static void loadpin_sb_free_security(struct super_block *mnt_sb)
{
/*
* When unmounting the filesystem we were using for load
* pinning, we acknowledge the superblock release, but make sure
* no other modules or firmware can be loaded.
*/
if (!IS_ERR_OR_NULL(pinned_root) && mnt_sb == pinned_root) {
pinned_root = ERR_PTR(-EIO);
pr_info("umount pinned fs: refusing further loads\n");
}
}
static int loadpin_read_file(struct file *file, enum kernel_read_file_id id,
bool contents)
{
struct super_block *load_root;
const char *origin = kernel_read_file_id_str(id);
/*
* If we will not know that we'll be seeing the full contents
* then we cannot trust a load will be complete and unchanged
* off disk. Treat all contents=false hooks as if there were
* no associated file struct.
*/
if (!contents)
file = NULL;
/* If the file id is excluded, ignore the pinning. */
if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
ignore_read_file_id[id]) {
report_load(origin, file, "pinning-excluded");
return 0;
}
/* This handles the older init_module API that has a NULL file. */
if (!file) {
if (!enforce) {
report_load(origin, NULL, "old-api-pinning-ignored");
return 0;
}
report_load(origin, NULL, "old-api-denied");
return -EPERM;
}
load_root = file->f_path.mnt->mnt_sb;
/* First loaded module/firmware defines the root for all others. */
spin_lock(&pinned_root_spinlock);
/*
* pinned_root is only NULL at startup. Otherwise, it is either
* a valid reference, or an ERR_PTR.
*/
if (!pinned_root) {
pinned_root = load_root;
/*
* Unlock now since it's only pinned_root we care about.
* In the worst case, we will (correctly) report pinning
* failures before we have announced that pinning is
* enforcing. This would be purely cosmetic.
*/
spin_unlock(&pinned_root_spinlock);
check_pinning_enforcement(pinned_root);
report_load(origin, file, "pinned");
} else {
spin_unlock(&pinned_root_spinlock);
}
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 18:35:25 +03:00
if (IS_ERR_OR_NULL(pinned_root) ||
((load_root != pinned_root) && !dm_verity_loadpin_is_bdev_trusted(load_root->s_bdev))) {
if (unlikely(!enforce)) {
report_load(origin, file, "pinning-ignored");
return 0;
}
report_load(origin, file, "denied");
return -EPERM;
}
return 0;
}
LSM: Introduce kernel_post_load_data() hook There are a few places in the kernel where LSMs would like to have visibility into the contents of a kernel buffer that has been loaded or read. While security_kernel_post_read_file() (which includes the buffer) exists as a pairing for security_kernel_read_file(), no such hook exists to pair with security_kernel_load_data(). Earlier proposals for just using security_kernel_post_read_file() with a NULL file argument were rejected (i.e. "file" should always be valid for the security_..._file hooks, but it appears at least one case was left in the kernel during earlier refactoring. (This will be fixed in a subsequent patch.) Since not all cases of security_kernel_load_data() can have a single contiguous buffer made available to the LSM hook (e.g. kexec image segments are separately loaded), there needs to be a way for the LSM to reason about its expectations of the hook coverage. In order to handle this, add a "contents" argument to the "kernel_load_data" hook that indicates if the newly added "kernel_post_load_data" hook will be called with the full contents once loaded. That way, LSMs requiring full contents can choose to unilaterally reject "kernel_load_data" with contents=false (which is effectively the existing hook coverage), but when contents=true they can allow it and later evaluate the "kernel_post_load_data" hook once the buffer is loaded. With this change, LSMs can gain coverage over non-file-backed data loads (e.g. init_module(2) and firmware userspace helper), which will happen in subsequent patches. Additionally prepare IMA to start processing these cases. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: KP Singh <kpsingh@google.com> Link: https://lore.kernel.org/r/20201002173828.2099543-9-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 20:38:20 +03:00
static int loadpin_load_data(enum kernel_load_data_id id, bool contents)
{
return loadpin_read_file(NULL, (enum kernel_read_file_id) id, contents);
}
static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(sb_free_security, loadpin_sb_free_security),
LSM_HOOK_INIT(kernel_read_file, loadpin_read_file),
LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
};
static void __init parse_exclude(void)
{
int i, j;
char *cur;
/*
* Make sure all the arrays stay within expected sizes. This
* is slightly weird because kernel_read_file_str[] includes
* READING_MAX_ID, which isn't actually meaningful here.
*/
BUILD_BUG_ON(ARRAY_SIZE(exclude_read_files) !=
ARRAY_SIZE(ignore_read_file_id));
BUILD_BUG_ON(ARRAY_SIZE(kernel_read_file_str) <
ARRAY_SIZE(ignore_read_file_id));
for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
cur = exclude_read_files[i];
if (!cur)
break;
if (*cur == '\0')
continue;
for (j = 0; j < ARRAY_SIZE(ignore_read_file_id); j++) {
if (strcmp(cur, kernel_read_file_str[j]) == 0) {
pr_info("excluding: %s\n",
kernel_read_file_str[j]);
ignore_read_file_id[j] = 1;
/*
* Can not break, because one read_file_str
* may map to more than on read_file_id.
*/
}
}
}
}
static int __init loadpin_init(void)
{
pr_info("ready to pin (currently %senforcing)\n",
enforce ? "" : "not ");
parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
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 18:35:25 +03:00
return 0;
}
DEFINE_LSM(loadpin) = {
.name = "loadpin",
.init = loadpin_init,
};
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 18:35:25 +03:00
#ifdef CONFIG_SECURITY_LOADPIN_VERITY
enum loadpin_securityfs_interface_index {
LOADPIN_DM_VERITY,
};
static int read_trusted_verity_root_digests(unsigned int fd)
{
struct fd f;
void *data;
int rc;
char *p, *d;
if (deny_reading_verity_digests)
return -EPERM;
/* The list of trusted root digests can only be set up once */
if (!list_empty(&dm_verity_loadpin_trusted_root_digests))
return -EPERM;
f = fdget(fd);
if (!f.file)
return -EINVAL;
data = kzalloc(SZ_4K, GFP_KERNEL);
if (!data) {
rc = -ENOMEM;
goto err;
}
rc = kernel_read_file(f.file, 0, (void **)&data, SZ_4K - 1, NULL, READING_POLICY);
if (rc < 0)
goto err;
p = data;
p[rc] = '\0';
p = strim(p);
p = strim(data);
while ((d = strsep(&p, "\n")) != NULL) {
int len;
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 18:35:25 +03:00
struct dm_verity_loadpin_trusted_root_digest *trd;
if (d == data) {
/* first line, validate header */
if (strcmp(d, VERITY_DIGEST_FILE_HEADER)) {
rc = -EPROTO;
goto err;
}
continue;
}
len = strlen(d);
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 18:35:25 +03:00
if (len % 2) {
rc = -EPROTO;
goto err;
}
len /= 2;
trd = kzalloc(struct_size(trd, data, len), GFP_KERNEL);
if (!trd) {
rc = -ENOMEM;
goto err;
}
if (hex2bin(trd->data, d, len)) {
kfree(trd);
rc = -EPROTO;
goto err;
}
trd->len = len;
list_add_tail(&trd->node, &dm_verity_loadpin_trusted_root_digests);
}
if (list_empty(&dm_verity_loadpin_trusted_root_digests)) {
rc = -EPROTO;
goto err;
}
kfree(data);
fdput(f);
return 0;
err:
kfree(data);
/* any failure in loading/parsing invalidates the entire list */
{
struct dm_verity_loadpin_trusted_root_digest *trd, *tmp;
list_for_each_entry_safe(trd, tmp, &dm_verity_loadpin_trusted_root_digests, node) {
list_del(&trd->node);
kfree(trd);
}
}
/* disallow further attempts after reading a corrupt/invalid file */
deny_reading_verity_digests = true;
fdput(f);
return rc;
}
/******************************** securityfs ********************************/
static long dm_verity_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
void __user *uarg = (void __user *)arg;
unsigned int fd;
switch (cmd) {
case LOADPIN_IOC_SET_TRUSTED_VERITY_DIGESTS:
if (copy_from_user(&fd, uarg, sizeof(fd)))
return -EFAULT;
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 18:35:25 +03:00
return read_trusted_verity_root_digests(fd);
default:
return -EINVAL;
}
}
static const struct file_operations loadpin_dm_verity_ops = {
.unlocked_ioctl = dm_verity_ioctl,
.compat_ioctl = compat_ptr_ioctl,
};
/**
* init_loadpin_securityfs - create the securityfs directory for LoadPin
*
* We can not put this method normally under the loadpin_init() code path since
* the security subsystem gets initialized before the vfs caches.
*
* Returns 0 if the securityfs directory creation was successful.
*/
static int __init init_loadpin_securityfs(void)
{
struct dentry *loadpin_dir, *dentry;
loadpin_dir = securityfs_create_dir("loadpin", NULL);
if (IS_ERR(loadpin_dir)) {
pr_err("LoadPin: could not create securityfs dir: %ld\n",
PTR_ERR(loadpin_dir));
return PTR_ERR(loadpin_dir);
}
dentry = securityfs_create_file("dm-verity", 0600, loadpin_dir,
(void *)LOADPIN_DM_VERITY, &loadpin_dm_verity_ops);
if (IS_ERR(dentry)) {
pr_err("LoadPin: could not create securityfs entry 'dm-verity': %ld\n",
PTR_ERR(dentry));
return PTR_ERR(dentry);
}
return 0;
}
fs_initcall(init_loadpin_securityfs);
#endif /* CONFIG_SECURITY_LOADPIN_VERITY */
/* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
module_param(enforce, int, 0);
MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");