| Message ID | 20220517163437.v4.1.I3e928575a23481121e73286874c4c2bdb403355d@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LoadPin: Enable loading from trusted dm-verity devices | expand |
On 18/05/2022 01:34, Matthias Kaehlcke wrote: > LoadPin limits loading of kernel modules, firmware and certain > other files to a 'pinned' file system (typically a read-only > rootfs). To provide more flexibility LoadPin is being extended > to also allow loading these files from trusted dm-verity > devices. For that purpose LoadPin can be provided with a list > of verity root digests that it should consider as trusted. > > Add a bunch of helpers to allow LoadPin to check whether a DM > device is a trusted verity device. The new functions broadly > fall in two categories: those that need access to verity > internals (like the root digest), and the 'glue' between > LoadPin and verity. The new file dm-verity-loadpin.c contains > the glue functions. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> ... > + > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > + return false; Almost unrelated note, but as there are more and more situations that checks verity root digest, shouldn't we export this as read-only sysfs attribute for DM verity devices? Attacker can always calculate (but not change) Merkle tree, so this is not something that need to be hidden. It would allow userspace to easily enumerate trusted DM devices without calling kernel ioctls... ... > + > + table = dm_get_live_table(md, &srcu_idx); > + > + if (dm_table_get_num_targets(table) != 1) > + goto out; > + > + ti = dm_table_get_target(table, 0); > + > + if (is_trusted_verity_target(ti)) > + trusted = true; What happens is someone reloads verity table later with a different content (or even different target type)? Does LoadPin even care here? ... > static struct target_type verity_target = { > .name = "verity", > .version = {1, 8, 0}, Please increase the minor version, it is very useful to detect (in logs) that the target driver has compatible extensions. I guess this change does not affect userspace veristysetup (as it is used handled by different tooling), right? Thanks, Milan
Hi Milan, On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote: > On 18/05/2022 01:34, Matthias Kaehlcke wrote: > > LoadPin limits loading of kernel modules, firmware and certain > > other files to a 'pinned' file system (typically a read-only > > rootfs). To provide more flexibility LoadPin is being extended > > to also allow loading these files from trusted dm-verity > > devices. For that purpose LoadPin can be provided with a list > > of verity root digests that it should consider as trusted. > > > > Add a bunch of helpers to allow LoadPin to check whether a DM > > device is a trusted verity device. The new functions broadly > > fall in two categories: those that need access to verity > > internals (like the root digest), and the 'glue' between > > LoadPin and verity. The new file dm-verity-loadpin.c contains > > the glue functions. > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > ... > > > + > > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > > + return false; > > Almost unrelated note, but as there are more and more situations > that checks verity root digest, shouldn't we export this as read-only > sysfs attribute for DM verity devices? > > Attacker can always calculate (but not change) Merkle tree, so this > is not something that need to be hidden. > > It would allow userspace to easily enumerate trusted DM devices without > calling kernel ioctls... I guess that's an option if there are scenarios where it is useful. It should probably be a separate patch, since it isn't directly related with extending LoadPin support to trusted verity devices. > > + > > + table = dm_get_live_table(md, &srcu_idx); > > + > > + if (dm_table_get_num_targets(table) != 1) > > + goto out; > > + > > + ti = dm_table_get_target(table, 0); > > + > > + if (is_trusted_verity_target(ti)) > > + trusted = true; > > What happens is someone reloads verity table later with > a different content (or even different target type)? > Does LoadPin even care here? LoadPin cares, but only when new kernel files are loaded. It will then check against the new verity table, and only allow loading of the file if it comes from a verity target with a trusted digest. > > static struct target_type verity_target = { > > .name = "verity", > > .version = {1, 8, 0}, > > Please increase the minor version, it is very useful to detect (in logs) > that the target driver has compatible extensions. I can do that, but would like to confirm that this is really needed/desired. This patch adds kernel-internal APIs which aren't accessible to userspace, that don't impact verity directly, so I'm not sure an increased minor version would be useful. > I guess this change does not affect userspace veristysetup > (as it is used handled by different tooling), right? Correct, from the verity side this is effectively a NOP, the new kernel-internal APIs only provide information to LoadPin, but don't change any verity specific behavior.
On Tue, May 17 2022 at 7:34P -0400, Matthias Kaehlcke <mka@chromium.org> wrote: > LoadPin limits loading of kernel modules, firmware and certain > other files to a 'pinned' file system (typically a read-only > rootfs). To provide more flexibility LoadPin is being extended > to also allow loading these files from trusted dm-verity > devices. For that purpose LoadPin can be provided with a list > of verity root digests that it should consider as trusted. > > Add a bunch of helpers to allow LoadPin to check whether a DM > device is a trusted verity device. The new functions broadly > fall in two categories: those that need access to verity > internals (like the root digest), and the 'glue' between > LoadPin and verity. The new file dm-verity-loadpin.c contains > the glue functions. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > --- > > Changes in v4: > - a trusted verity device must have a single target of > type 'verity' > - share list of verity digests with loadpin, deleted > dm_verity_loadpin_set_trusted_root_digests() > - dm_verity_loadpin_is_md_trusted() is now dm_verity_loadpin_is_sb_trusted(), > it receives a super_block instead of mapped_device. Updated kernel doc. > - changed struct trusted_root_digest to have an unsized > u8 array instead of a pointer > - extend 'dm-verity-objs' instead of 'dm-mod-objs' > > Changes in v3: > - none > > Changes in v2: > - none > > drivers/md/Makefile | 6 +++ > drivers/md/dm-verity-loadpin.c | 74 +++++++++++++++++++++++++++++++ > drivers/md/dm-verity-target.c | 33 ++++++++++++++ > drivers/md/dm-verity.h | 4 ++ > include/linux/dm-verity-loadpin.h | 27 +++++++++++ > 5 files changed, 144 insertions(+) > create mode 100644 drivers/md/dm-verity-loadpin.c > create mode 100644 include/linux/dm-verity-loadpin.h > > diff --git a/drivers/md/Makefile b/drivers/md/Makefile > index 0454b0885b01..71771901c823 100644 > --- a/drivers/md/Makefile > +++ b/drivers/md/Makefile > @@ -108,6 +108,12 @@ ifeq ($(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG),y) > dm-verity-objs += dm-verity-verify-sig.o > endif > > +ifeq ($(CONFIG_DM_VERITY),y) > +ifeq ($(CONFIG_SECURITY_LOADPIN),y) > +dm-verity-objs += dm-verity-loadpin.o > +endif > +endif > + > ifeq ($(CONFIG_DM_AUDIT),y) > dm-mod-objs += dm-audit.o > endif > diff --git a/drivers/md/dm-verity-loadpin.c b/drivers/md/dm-verity-loadpin.c > new file mode 100644 > index 000000000000..3226fbe4a1fe > --- /dev/null > +++ b/drivers/md/dm-verity-loadpin.c > @@ -0,0 +1,74 @@ > +// SPDX-License-Identifier: GPL-2.0-only > + > +#include <linux/list.h> > +#include <linux/kernel.h> > +#include <linux/dm-verity-loadpin.h> > + > +#include "dm.h" > +#include "dm-verity.h" > + > +#define DM_MSG_PREFIX "verity-loadpin" > + > +LIST_HEAD(loadpin_trusted_verity_root_digests); > + > +static bool is_trusted_verity_target(struct dm_target *ti) > +{ > + u8 *root_digest; > + unsigned int digest_size; > + struct trusted_root_digest *trd; > + bool trusted = false; > + > + if (!dm_is_verity_target(ti)) > + return false; > + > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > + return false; > + > + list_for_each_entry(trd, &loadpin_trusted_verity_root_digests, node) { > + if ((trd->len == digest_size) && > + !memcmp(trd->data, root_digest, digest_size)) { > + trusted = true; > + break; > + } > + } > + > + kfree(root_digest); > + > + return trusted; > +} > + > +/* > + * Determines whether the file system of a superblock is located on > + * a verity device that is trusted by LoadPin. > + */ > +bool dm_verity_loadpin_is_sb_trusted(struct super_block *sb) > +{ > + struct mapped_device *md; > + struct dm_table *table; > + struct dm_target *ti; > + int srcu_idx; > + bool trusted = false; > + > + if (list_empty(&loadpin_trusted_verity_root_digests)) > + return false; > + > + md = dm_get_md(sb->s_bdev->bd_dev); > + if (!md) > + return false; > + > + table = dm_get_live_table(md, &srcu_idx); > + > + if (dm_table_get_num_targets(table) != 1) > + goto out; > + > + ti = dm_table_get_target(table, 0); > + > + if (is_trusted_verity_target(ti)) > + trusted = true; > + > +out: > + dm_put_live_table(md, srcu_idx); > + dm_put(md); > + > + return trusted; > +} Not seeing why passing a super_block a block layer interface was chosen. Please pass the super_block's block_device and rename to dm_verity_loadpin_is_bdev_trusted() Thanks, Mike
On Wed, May 18 2022 at 11:13P -0400, Matthias Kaehlcke <mka@chromium.org> wrote: > Hi Milan, > > On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote: > > On 18/05/2022 01:34, Matthias Kaehlcke wrote: > > > LoadPin limits loading of kernel modules, firmware and certain > > > other files to a 'pinned' file system (typically a read-only > > > rootfs). To provide more flexibility LoadPin is being extended > > > to also allow loading these files from trusted dm-verity > > > devices. For that purpose LoadPin can be provided with a list > > > of verity root digests that it should consider as trusted. > > > > > > Add a bunch of helpers to allow LoadPin to check whether a DM > > > device is a trusted verity device. The new functions broadly > > > fall in two categories: those that need access to verity > > > internals (like the root digest), and the 'glue' between > > > LoadPin and verity. The new file dm-verity-loadpin.c contains > > > the glue functions. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > ... > > > > > + > > > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > > > + return false; > > > > Almost unrelated note, but as there are more and more situations > > that checks verity root digest, shouldn't we export this as read-only > > sysfs attribute for DM verity devices? > > > > Attacker can always calculate (but not change) Merkle tree, so this > > is not something that need to be hidden. > > > > It would allow userspace to easily enumerate trusted DM devices without > > calling kernel ioctls... > > I guess that's an option if there are scenarios where it is useful. It > should probably be a separate patch, since it isn't directly related with > extending LoadPin support to trusted verity devices. > > > > + > > > + table = dm_get_live_table(md, &srcu_idx); > > > + > > > + if (dm_table_get_num_targets(table) != 1) > > > + goto out; > > > + > > > + ti = dm_table_get_target(table, 0); > > > + > > > + if (is_trusted_verity_target(ti)) > > > + trusted = true; > > > > What happens is someone reloads verity table later with > > a different content (or even different target type)? > > Does LoadPin even care here? > > LoadPin cares, but only when new kernel files are loaded. It will then check > against the new verity table, and only allow loading of the file if it comes > from a verity target with a trusted digest. > > > > static struct target_type verity_target = { > > > .name = "verity", > > > .version = {1, 8, 0}, > > > > Please increase the minor version, it is very useful to detect (in logs) > > that the target driver has compatible extensions. > > I can do that, but would like to confirm that this is really needed/desired. > This patch adds kernel-internal APIs which aren't accessible to userspace, > that don't impact verity directly, so I'm not sure an increased minor version > would be useful. Bumping to 1.8.1 is useful to indicate new changes that offer expanded use of the verity target (even if by LoadPin).
On Wed, May 18, 2022 at 04:03:44PM -0400, Mike Snitzer wrote: > On Wed, May 18 2022 at 11:13P -0400, > Matthias Kaehlcke <mka@chromium.org> wrote: > > > Hi Milan, > > > > On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote: > > > On 18/05/2022 01:34, Matthias Kaehlcke wrote: > > > > LoadPin limits loading of kernel modules, firmware and certain > > > > other files to a 'pinned' file system (typically a read-only > > > > rootfs). To provide more flexibility LoadPin is being extended > > > > to also allow loading these files from trusted dm-verity > > > > devices. For that purpose LoadPin can be provided with a list > > > > of verity root digests that it should consider as trusted. > > > > > > > > Add a bunch of helpers to allow LoadPin to check whether a DM > > > > device is a trusted verity device. The new functions broadly > > > > fall in two categories: those that need access to verity > > > > internals (like the root digest), and the 'glue' between > > > > LoadPin and verity. The new file dm-verity-loadpin.c contains > > > > the glue functions. > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > ... > > > > > > > + > > > > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > > > > + return false; > > > > > > Almost unrelated note, but as there are more and more situations > > > that checks verity root digest, shouldn't we export this as read-only > > > sysfs attribute for DM verity devices? > > > > > > Attacker can always calculate (but not change) Merkle tree, so this > > > is not something that need to be hidden. > > > > > > It would allow userspace to easily enumerate trusted DM devices without > > > calling kernel ioctls... > > > > I guess that's an option if there are scenarios where it is useful. It > > should probably be a separate patch, since it isn't directly related with > > extending LoadPin support to trusted verity devices. > > > > > > + > > > > + table = dm_get_live_table(md, &srcu_idx); > > > > + > > > > + if (dm_table_get_num_targets(table) != 1) > > > > + goto out; > > > > + > > > > + ti = dm_table_get_target(table, 0); > > > > + > > > > + if (is_trusted_verity_target(ti)) > > > > + trusted = true; > > > > > > What happens is someone reloads verity table later with > > > a different content (or even different target type)? > > > Does LoadPin even care here? > > > > LoadPin cares, but only when new kernel files are loaded. It will then check > > against the new verity table, and only allow loading of the file if it comes > > from a verity target with a trusted digest. > > > > > > static struct target_type verity_target = { > > > > .name = "verity", > > > > .version = {1, 8, 0}, > > > > > > Please increase the minor version, it is very useful to detect (in logs) > > > that the target driver has compatible extensions. > > > > I can do that, but would like to confirm that this is really needed/desired. > > This patch adds kernel-internal APIs which aren't accessible to userspace, > > that don't impact verity directly, so I'm not sure an increased minor version > > would be useful. > > Bumping to 1.8.1 is useful to indicate new changes that offer expanded > use of the verity target (even if by LoadPin). Ok, I'll bump the version, thanks for the confirmation.
On Wed, May 18, 2022 at 03:52:21PM -0400, Mike Snitzer wrote: > On Tue, May 17 2022 at 7:34P -0400, > Matthias Kaehlcke <mka@chromium.org> wrote: > > > LoadPin limits loading of kernel modules, firmware and certain > > other files to a 'pinned' file system (typically a read-only > > rootfs). To provide more flexibility LoadPin is being extended > > to also allow loading these files from trusted dm-verity > > devices. For that purpose LoadPin can be provided with a list > > of verity root digests that it should consider as trusted. > > > > Add a bunch of helpers to allow LoadPin to check whether a DM > > device is a trusted verity device. The new functions broadly > > fall in two categories: those that need access to verity > > internals (like the root digest), and the 'glue' between > > LoadPin and verity. The new file dm-verity-loadpin.c contains > > the glue functions. > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > --- > > > > Changes in v4: > > - a trusted verity device must have a single target of > > type 'verity' > > - share list of verity digests with loadpin, deleted > > dm_verity_loadpin_set_trusted_root_digests() > > - dm_verity_loadpin_is_md_trusted() is now dm_verity_loadpin_is_sb_trusted(), > > it receives a super_block instead of mapped_device. Updated kernel doc. > > - changed struct trusted_root_digest to have an unsized > > u8 array instead of a pointer > > - extend 'dm-verity-objs' instead of 'dm-mod-objs' > > > > Changes in v3: > > - none > > > > Changes in v2: > > - none > > > > drivers/md/Makefile | 6 +++ > > drivers/md/dm-verity-loadpin.c | 74 +++++++++++++++++++++++++++++++ > > drivers/md/dm-verity-target.c | 33 ++++++++++++++ > > drivers/md/dm-verity.h | 4 ++ > > include/linux/dm-verity-loadpin.h | 27 +++++++++++ > > 5 files changed, 144 insertions(+) > > create mode 100644 drivers/md/dm-verity-loadpin.c > > create mode 100644 include/linux/dm-verity-loadpin.h > > > > diff --git a/drivers/md/Makefile b/drivers/md/Makefile > > index 0454b0885b01..71771901c823 100644 > > --- a/drivers/md/Makefile > > +++ b/drivers/md/Makefile > > @@ -108,6 +108,12 @@ ifeq ($(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG),y) > > dm-verity-objs += dm-verity-verify-sig.o > > endif > > > > +ifeq ($(CONFIG_DM_VERITY),y) > > +ifeq ($(CONFIG_SECURITY_LOADPIN),y) > > +dm-verity-objs += dm-verity-loadpin.o > > +endif > > +endif > > + > > ifeq ($(CONFIG_DM_AUDIT),y) > > dm-mod-objs += dm-audit.o > > endif > > diff --git a/drivers/md/dm-verity-loadpin.c b/drivers/md/dm-verity-loadpin.c > > new file mode 100644 > > index 000000000000..3226fbe4a1fe > > --- /dev/null > > +++ b/drivers/md/dm-verity-loadpin.c > > @@ -0,0 +1,74 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > + > > +#include <linux/list.h> > > +#include <linux/kernel.h> > > +#include <linux/dm-verity-loadpin.h> > > + > > +#include "dm.h" > > +#include "dm-verity.h" > > + > > +#define DM_MSG_PREFIX "verity-loadpin" > > + > > +LIST_HEAD(loadpin_trusted_verity_root_digests); > > + > > +static bool is_trusted_verity_target(struct dm_target *ti) > > +{ > > + u8 *root_digest; > > + unsigned int digest_size; > > + struct trusted_root_digest *trd; > > + bool trusted = false; > > + > > + if (!dm_is_verity_target(ti)) > > + return false; > > + > > + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) > > + return false; > > + > > + list_for_each_entry(trd, &loadpin_trusted_verity_root_digests, node) { > > + if ((trd->len == digest_size) && > > + !memcmp(trd->data, root_digest, digest_size)) { > > + trusted = true; > > + break; > > + } > > + } > > + > > + kfree(root_digest); > > + > > + return trusted; > > +} > > + > > +/* > > + * Determines whether the file system of a superblock is located on > > + * a verity device that is trusted by LoadPin. > > + */ > > +bool dm_verity_loadpin_is_sb_trusted(struct super_block *sb) > > +{ > > + struct mapped_device *md; > > + struct dm_table *table; > > + struct dm_target *ti; > > + int srcu_idx; > > + bool trusted = false; > > + > > + if (list_empty(&loadpin_trusted_verity_root_digests)) > > + return false; > > + > > + md = dm_get_md(sb->s_bdev->bd_dev); > > + if (!md) > > + return false; > > + > > + table = dm_get_live_table(md, &srcu_idx); > > + > > + if (dm_table_get_num_targets(table) != 1) > > + goto out; > > + > > + ti = dm_table_get_target(table, 0); > > + > > + if (is_trusted_verity_target(ti)) > > + trusted = true; > > + > > +out: > > + dm_put_live_table(md, srcu_idx); > > + dm_put(md); > > + > > + return trusted; > > +} > > Not seeing why passing a super_block a block layer interface was > chosen. > > Please pass the super_block's block_device and rename to > dm_verity_loadpin_is_bdev_trusted() Agreed, passing a block_device is a better choice here, I'll change it as suggested.
diff --git a/drivers/md/Makefile b/drivers/md/Makefile index 0454b0885b01..71771901c823 100644 --- a/drivers/md/Makefile +++ b/drivers/md/Makefile @@ -108,6 +108,12 @@ ifeq ($(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG),y) dm-verity-objs += dm-verity-verify-sig.o endif +ifeq ($(CONFIG_DM_VERITY),y) +ifeq ($(CONFIG_SECURITY_LOADPIN),y) +dm-verity-objs += dm-verity-loadpin.o +endif +endif + ifeq ($(CONFIG_DM_AUDIT),y) dm-mod-objs += dm-audit.o endif diff --git a/drivers/md/dm-verity-loadpin.c b/drivers/md/dm-verity-loadpin.c new file mode 100644 index 000000000000..3226fbe4a1fe --- /dev/null +++ b/drivers/md/dm-verity-loadpin.c @@ -0,0 +1,74 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/list.h> +#include <linux/kernel.h> +#include <linux/dm-verity-loadpin.h> + +#include "dm.h" +#include "dm-verity.h" + +#define DM_MSG_PREFIX "verity-loadpin" + +LIST_HEAD(loadpin_trusted_verity_root_digests); + +static bool is_trusted_verity_target(struct dm_target *ti) +{ + u8 *root_digest; + unsigned int digest_size; + struct trusted_root_digest *trd; + bool trusted = false; + + if (!dm_is_verity_target(ti)) + return false; + + if (dm_verity_get_root_digest(ti, &root_digest, &digest_size)) + return false; + + list_for_each_entry(trd, &loadpin_trusted_verity_root_digests, node) { + if ((trd->len == digest_size) && + !memcmp(trd->data, root_digest, digest_size)) { + trusted = true; + break; + } + } + + kfree(root_digest); + + return trusted; +} + +/* + * Determines whether the file system of a superblock is located on + * a verity device that is trusted by LoadPin. + */ +bool dm_verity_loadpin_is_sb_trusted(struct super_block *sb) +{ + struct mapped_device *md; + struct dm_table *table; + struct dm_target *ti; + int srcu_idx; + bool trusted = false; + + if (list_empty(&loadpin_trusted_verity_root_digests)) + return false; + + md = dm_get_md(sb->s_bdev->bd_dev); + if (!md) + return false; + + table = dm_get_live_table(md, &srcu_idx); + + if (dm_table_get_num_targets(table) != 1) + goto out; + + ti = dm_table_get_target(table, 0); + + if (is_trusted_verity_target(ti)) + trusted = true; + +out: + dm_put_live_table(md, srcu_idx); + dm_put(md); + + return trusted; +} diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index 80133aae0db3..6f07b849fcb2 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -19,6 +19,7 @@ #include <linux/module.h> #include <linux/reboot.h> #include <linux/scatterlist.h> +#include <linux/string.h> #define DM_MSG_PREFIX "verity" @@ -1310,6 +1311,38 @@ static int verity_ctr(struct dm_target *ti, unsigned argc, char **argv) return r; } +/* + * Check whether a DM target is a verity target. + */ +bool dm_is_verity_target(struct dm_target *ti) +{ + return ti->type->module == THIS_MODULE; +} +EXPORT_SYMBOL_GPL(dm_is_verity_target); + +/* + * Get the root digest of a verity target. + * + * Returns a copy of the root digest, the caller is responsible for + * freeing the memory of the digest. + */ +int dm_verity_get_root_digest(struct dm_target *ti, u8 **root_digest, unsigned int *digest_size) +{ + struct dm_verity *v = ti->private; + + if (!dm_is_verity_target(ti)) + return -EINVAL; + + *root_digest = kmemdup(v->root_digest, v->digest_size, GFP_KERNEL); + if (*root_digest == NULL) + return -ENOMEM; + + *digest_size = v->digest_size; + + return 0; +} +EXPORT_SYMBOL_GPL(dm_verity_get_root_digest); + static struct target_type verity_target = { .name = "verity", .version = {1, 8, 0}, diff --git a/drivers/md/dm-verity.h b/drivers/md/dm-verity.h index 4e769d13473a..c832cc3e3d24 100644 --- a/drivers/md/dm-verity.h +++ b/drivers/md/dm-verity.h @@ -129,4 +129,8 @@ extern int verity_hash(struct dm_verity *v, struct ahash_request *req, extern int verity_hash_for_block(struct dm_verity *v, struct dm_verity_io *io, sector_t block, u8 *digest, bool *is_zero); +extern bool dm_is_verity_target(struct dm_target *ti); +extern int dm_verity_get_root_digest(struct dm_target *ti, u8 **root_digest, + unsigned int *digest_size); + #endif /* DM_VERITY_H */ diff --git a/include/linux/dm-verity-loadpin.h b/include/linux/dm-verity-loadpin.h new file mode 100644 index 000000000000..c2bfd2b9c651 --- /dev/null +++ b/include/linux/dm-verity-loadpin.h @@ -0,0 +1,27 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef __LINUX_DM_VERITY_LOADPIN_H +#define __LINUX_DM_VERITY_LOADPIN_H + +#include <linux/list.h> + +struct super_block; + +extern struct list_head loadpin_trusted_verity_root_digests; + +struct trusted_root_digest { + struct list_head node; + unsigned int len; + u8 data[]; +}; + +#if IS_ENABLED(CONFIG_SECURITY_LOADPIN) && IS_BUILTIN(CONFIG_DM_VERITY) +bool dm_verity_loadpin_is_sb_trusted(struct super_block *sb); +#else +static inline bool dm_verity_loadpin_is_sb_trusted(struct super_block *sb); +{ + return false; +} +#endif + +#endif /* __LINUX_DM_LOADPIN_H */
LoadPin limits loading of kernel modules, firmware and certain other files to a 'pinned' file system (typically a read-only rootfs). To provide more flexibility LoadPin is being extended to also allow loading these files from trusted dm-verity devices. For that purpose LoadPin can be provided with a list of verity root digests that it should consider as trusted. Add a bunch of helpers to allow LoadPin to check whether a DM device is a trusted verity device. The new functions broadly fall in two categories: those that need access to verity internals (like the root digest), and the 'glue' between LoadPin and verity. The new file dm-verity-loadpin.c contains the glue functions. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> --- Changes in v4: - a trusted verity device must have a single target of type 'verity' - share list of verity digests with loadpin, deleted dm_verity_loadpin_set_trusted_root_digests() - dm_verity_loadpin_is_md_trusted() is now dm_verity_loadpin_is_sb_trusted(), it receives a super_block instead of mapped_device. Updated kernel doc. - changed struct trusted_root_digest to have an unsized u8 array instead of a pointer - extend 'dm-verity-objs' instead of 'dm-mod-objs' Changes in v3: - none Changes in v2: - none drivers/md/Makefile | 6 +++ drivers/md/dm-verity-loadpin.c | 74 +++++++++++++++++++++++++++++++ drivers/md/dm-verity-target.c | 33 ++++++++++++++ drivers/md/dm-verity.h | 4 ++ include/linux/dm-verity-loadpin.h | 27 +++++++++++ 5 files changed, 144 insertions(+) create mode 100644 drivers/md/dm-verity-loadpin.c create mode 100644 include/linux/dm-verity-loadpin.h