Verified boot tooling
Subsystems (3)
cover Verified boot tooling
Hi,
As my previous patches were eaten by the mailman because I hadn't subscribed to the mailing list, this is a resend so that all can see.
From the comments currently this is probbably not the way to approach what I am trying to do, but is interesting nevertheless.
My goal is to have a UBI containing a squashfs volume, dm-verity hash table, and kernel FIT.
Currently the way to do that would be get buildroot to generate the individual artifacts, rootfs.squashfs, zImage, some.dtb, then assemble the UBI per board. Using post_image processingi, hash the rootfs.squashfs with veritysetup, assemble the FIT, then assemble with ubinize directly (or genimage now that I see there is FIT support ~4 days ago).
As there are already KConfigs around the various ubinize options for ubi+ubifs I split these apart and added depends so that the UBI step came last. This meant that my ubinize.cfg could point at the squashfs and verity artifacts.
I'm happy either way, if post processing is the way to go so be it but it seems there may be a lot of duplicated code of people attempting the same sort of things, quite a lot just point at or wrap genimage.
Thanks,
Ben Whitten (2):
fs/ubi: decouple ubi & ubifs
fs/squashfs: enable squashfs to generate a verity hashtable
fs/Config.in | 3 ++- fs/squashfs/Config.in | 6 ++++++ fs/squashfs/squashfs.mk | 10 ++++++++++ fs/ubi/Config.in | 34 +++++++++++++++++++++++++++++++--- fs/ubi/ubi.mk | 14 +++++++++++++- fs/ubi/ubinize.cfg | 4 ++-- fs/ubifs/Config.in | 2 ++ 7 files changed, 66 insertions(+), 7 deletions(-)
Signature · 1 line
2.7.4
PATCH RESEND 1/2 fs/ubi: decouple ubi & ubifs
As ubi is a container it shouldn't enforce a ubifs rootfs to be built, it is reasonable to have a squashfs ro filesystem within a ubi. If ubifs is selected ubi containing ubifs is automatically selected as to not break existing configs
--- fs/Config.in | 3 ++- fs/ubi/Config.in | 34 +++++++++++++++++++++++++++++++--- fs/ubi/ubi.mk | 14 +++++++++++++- fs/ubi/ubinize.cfg | 4 ++-- fs/ubifs/Config.in | 2 ++ 5 files changed, 50 insertions(+), 7 deletions(-)
fs/Config.in +2 -1
@@ -11,8 +11,9 @@ source "fs/jffs2/Config.in" source "fs/romfs/Config.in" source "fs/squashfs/Config.in" source "fs/tar/Config.in" -source "fs/ubi/Config.in" source "fs/ubifs/Config.in" source "fs/yaffs2/Config.in" +comment "Container" +source "fs/ubi/Config.in" endmenu
fs/ubi/Config.in +31 -3
@@ -1,11 +1,30 @@ config BR2_TARGET_ROOTFS_UBI - bool "ubi image containing an ubifs root filesystem" - select BR2_TARGET_ROOTFS_UBIFS + bool "ubi image containing a root filesystem" help - Build an ubi image from the ubifs one (with ubinize). + Build a ubi image from the selected filesystems (with ubinize). if BR2_TARGET_ROOTFS_UBI +choice + prompt "UBI Container" + default BR2_TARGET_ROOTFS_UBIFS + +config BR2_TARGET_ROOTFS_UBI_CONTAINS_UBIFS + bool "containing a ubifs filesystem" + depends on BR2_TARGET_ROOTFS_UBIFS + help + Select this option to have the ubi contain the ubifs filesystem + this is the default behaviour. + +config BR2_TARGET_ROOTFS_UBI_CONTAINS_SQUASHFS + bool "containing a squashfs filesystem" + depends on BR2_TARGET_ROOTFS_SQUASHFS + help + Select this option to have the ubi contain the squashfs + filesystem. Useful for readonly systems. + +endchoice + config BR2_TARGET_ROOTFS_UBI_PEBSIZE hex "physical eraseblock size" default 0x20000
@@ -14,6 +33,15 @@ config BR2_TARGET_ROOTFS_UBI_PEBSIZE flash chip the ubi image is created for. The value provided here is passed to the -p/--peb-size option of ubinize. +config BR2_TARGET_ROOTFS_UBI_MINIOSIZE + hex "minimum I/O unit size" + depends on !BR2_TARGET_ROOTFS_UBIFS + default 0x800 + help + Minimum I/O unit size. The value provided here is passed + to the -m/--min-io-size option of ubinize. + + config BR2_TARGET_ROOTFS_UBI_SUBSIZE int "sub-page size" default 512
fs/ubi/ubi.mk +13 -1
@@ -4,7 +4,12 @@ # ################################################################################ +ifneq ($(BR2_TARGET_ROOTFS_UBIFS),y) +UBI_UBINIZE_OPTS := -m $(BR2_TARGET_ROOTFS_UBI_MINIOSIZE) +else UBI_UBINIZE_OPTS := -m $(BR2_TARGET_ROOTFS_UBIFS_MINIOSIZE) +endif + UBI_UBINIZE_OPTS += -p $(BR2_TARGET_ROOTFS_UBI_PEBSIZE) ifneq ($(BR2_TARGET_ROOTFS_UBI_SUBSIZE),0) UBI_UBINIZE_OPTS += -s $(BR2_TARGET_ROOTFS_UBI_SUBSIZE)
@@ -12,7 +17,14 @@ endif UBI_UBINIZE_OPTS += $(call qstrip,$(BR2_TARGET_ROOTFS_UBI_OPTS)) +ifeq ($(BR2_TARGET_ROOTFS_UBI_CONTAINS_UBIFS),y) ROOTFS_UBI_DEPENDENCIES = rootfs-ubifs +ROOTFS_UBI_ROOTFS_EXT = .ubifs +else ifeq ($(BR2_TARGET_ROOTFS_UBI_CONTAINS_SQUASHFS),y) +ROOTFS_UBI_DEPENDENCIES = rootfs-squashfs +ROOTFS_UBI_ROOTFS_EXT = .squashfs +endif +ROOTFS_UBI_DEPENDENCIES += host-mtd ifeq ($(BR2_TARGET_ROOTFS_UBI_USE_CUSTOM_CONFIG),y) UBINIZE_CONFIG_FILE_PATH = $(call qstrip,$(BR2_TARGET_ROOTFS_UBI_CUSTOM_CONFIG_FILE))
@@ -23,7 +35,7 @@ endif # don't use sed -i as it misbehaves on systems with SELinux enabled when this is # executed through fakeroot (see #9386) define ROOTFS_UBI_CMD - sed 's;BR2_ROOTFS_UBIFS_PATH;$@fs;' \ + sed 's;BR2_ROOTFS_PATH;$(BINARIES_DIR)/rootfs$(ROOTFS_UBI_ROOTFS_EXT);' \ $(UBINIZE_CONFIG_FILE_PATH) > $(BUILD_DIR)/ubinize.cfg $(HOST_DIR)/sbin/ubinize -o $@ $(UBI_UBINIZE_OPTS) $(BUILD_DIR)/ubinize.cfg rm $(BUILD_DIR)/ubinize.cfg
fs/ubi/ubinize.cfg +2 -2
@@ -1,8 +1,8 @@ -[ubifs] +[rootfs] mode=ubi vol_id=0 vol_type=dynamic vol_name=rootfs vol_alignment=1 vol_flags=autoresize -image=BR2_ROOTFS_UBIFS_PATH +image=BR2_ROOTFS_PATH
fs/ubifs/Config.in +2 -0
@@ -1,5 +1,7 @@ config BR2_TARGET_ROOTFS_UBIFS bool "ubifs root filesystem" + depends on BR2_TARGET_ROOTFS_UBI + select BR2_TARGET_ROOTFS_UBI_CONTAINS_UBIFS help Build a ubifs root filesystem
Signature · 1 line
2.7.4
PATCH RESEND 1/2 fs/ubi: decouple ubi & ubifs
Ben,
Quoted 4 lines · Ben Whitten
As ubi is a container it shouldn't enforce a ubifs rootfs to be built, it is reasonable to have a squashfs ro filesystem within a ubi. If ubifs is selected ubi containing ubifs is automatically selected as to not break existing configs
What are you thoughts on the usecase of needing the Kernel/DTB FIT (or other firmware) images also in UBI?
i.e. when online creating the UBI partitions, I can see creating a single UBI and then just treating it like a raw device to store a series of blobs (firmware, rootfs & kernel). Generation of something
like that offline feels like a post image activity. However, I guess
that case could just be a new image containerization option which acts like a general hook to take a series of files (for each create a UBI container). On target for that option, there would be more MTD devices vs a single (I'd have to revisit the limitations of a single UBI vs one for each image as I'm unsure of which is better).
I wonder how often a design would end up using a combination of a post script and buildroot doing UBI generation where they have to maintain both? Depending on that, I think I'd argue for defaulting to a post script
Matt
PATCH RESEND 1/2 fs/ubi: decouple ubi & ubifs
Quoted 8 lines · Matthew Weber
Ben,
Quoted 4 lines · Ben Whitten
As ubi is a container it shouldn't enforce a ubifs rootfs to be built, it is reasonable to have a squashfs ro filesystem within a ubi. If ubifs is selected ubi containing ubifs is automatically selected as to not break existing configs
Quoted 7 lines
What are you thoughts on the usecase of needing the Kernel/DTB FIT (or other firmware) images also in UBI?
i.e. when online creating the UBI partitions, I can see creating a single UBI and then just treating it like a raw device to store a series of blobs (firmware, rootfs & kernel). Generation of something like that offline feels like a post image activity.
So in my context the final 'image' is something I would deliver to our factory for
flashing in production. In this case our UBI needs it all, kernel a/b rootfs a/b etc.
And its the individual artifacts that sw update gets generated from.
Quoted 6 lines
However, I guess
that case could just be a new image containerization option which acts like a general hook to take a series of files (for each create a UBI container). On target for that option, there would be more MTD devices vs a single (I'd have to revisit the limitations of a single UBI vs one for each image as I'm unsure of which is better).
It makes sense to have the UBI as large as possible to take advantage of wear leveling across the full flash, instead of artificially limiting their range. Thats what
the volumes would be for within the UBI.
Quoted 4 lines
I wonder how often a design would end up using a combination of a post script and buildroot doing UBI generation where they have to maintain both? Depending on that, I think I'd argue for defaulting to a post script
True. I think justing having BR generate artifacts then have genimage assemble to what ever format required seems to be the defacto solution. Perhaps that could be integrated as an option instead of having to call it in numerous boards as a post script.
Ben
PATCH RESEND 1/2 fs/ubi: decouple ubi & ubifs
Hi Ben,
Quoted 18 lines · Ben Whitten
Quoted 8 lines · Matthew Weber
Ben,
Quoted 4 lines · Ben Whitten
As ubi is a container it shouldn't enforce a ubifs rootfs to be built, it is reasonable to have a squashfs ro filesystem within a ubi. If ubifs is selected ubi containing ubifs is automatically selected as to not break existing configs
Quoted 7 lines
What are you thoughts on the usecase of needing the Kernel/DTB FIT (or other firmware) images also in UBI?
i.e. when online creating the UBI partitions, I can see creating a single UBI and then just treating it like a raw device to store a series of blobs (firmware, rootfs & kernel). Generation of something like that offline feels like a post image activity.
Quoted 4 lines
So in my context the final 'image' is something I would deliver to our factory for
flashing in production. In this case our UBI needs it all, kernel a/b rootfs a/b etc.
I generally find it easier in practice to format the UBI partition "online" in
a production script, and then add the UBI(FS) volumes to it one by one. That makes it easier to make sure the UBI extends to the full partition. Otherwise, it depends a bit on your flasher what is done with bad blocks in your image.
Quoted 19 lines
And its the individual artifacts that sw update gets generated from.
Quoted 6 lines
However, I guess
that case could just be a new image containerization option which acts like a general hook to take a series of files (for each create a UBI container). On target for that option, there would be more MTD devices vs a single (I'd have to revisit the limitations of a single UBI vs one for each image as I'm unsure of which is better).It makes sense to have the UBI as large as possible to take advantage of wear leveling across the full flash, instead of artificially limiting their range. Thats what
the volumes would be for within the UBI.Quoted 4 lines
I wonder how often a design would end up using a combination of a post script and buildroot doing UBI generation where they have to maintain both? Depending on that, I think I'd argue for defaulting to a post script
Quoted 4 lines
True. I think justing having BR generate artifacts then have genimage assemble to what ever format required seems to be the defacto solution. Perhaps that could be integrated as an option instead of having to call it in numerous boards as a post script.
Well, you can usually use support/scripts/genimage.sh directly as the
post-image script and just set the appropriate options in BR2_ROOTFS_POST_SCRIPT_ARGS. Like is done in numerous defconfigs.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH RESEND 2/2 fs/squashfs: enable squashfs to generate a verity hashtable
In reply to Ben WhittenFor those times that you want to verify that your readonly filesystem hasn't been tampered we can generate a dm-verity hash table. The root hash is enclosed in .table file and must be secured else where.
--- fs/squashfs/Config.in | 6 ++++++ fs/squashfs/squashfs.mk | 10 ++++++++++ 2 files changed, 16 insertions(+)
fs/squashfs/Config.in +6 -0
@@ -28,4 +28,10 @@ config BR2_TARGET_ROOTFS_SQUASHFS4_XZ bool "xz" endchoice + +config BR2_TARGET_ROOTFS_SQUASHFS_VERITY + bool "Generate verity hashtable" + help + As squashfs is readonly it is possible to generate a dm-verity + hashtable for use in verified boot systems. endif
fs/squashfs/squashfs.mk +10 -0
@@ -5,6 +5,9 @@ ################################################################################ ROOTFS_SQUASHFS_DEPENDENCIES = host-squashfs +ifeq ($(BR2_TARGET_ROOTFS_SQUASHFS_VERITY),y) +ROOTFS_SQUASHFS_DEPENDENCIES += host-cryptsetup +endif ROOTFS_SQUASHFS_ARGS = -noappend -processors $(PARALLEL_JOBS)
@@ -24,4 +27,11 @@ define ROOTFS_SQUASHFS_CMD $(HOST_DIR)/bin/mksquashfs $(TARGET_DIR) $@ $(ROOTFS_SQUASHFS_ARGS) endef +ifeq ($(BR2_TARGET_ROOTFS_SQUASHFS_VERITY),y) +define ROOTFS_SQUASHFS_VERITY + $(HOST_DIR)/sbin/veritysetup format $@ [email protected] > [email protected] +endef +ROOTFS_SQUASHFS_POST_GEN_HOOKS += ROOTFS_SQUASHFS_VERITY +endif + $(eval $(rootfs))
Signature · 1 line
2.7.4
PATCH RESEND 2/2 fs/squashfs: enable squashfs to generate a verity hashtable
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ben" == Ben Whitten <[email protected]> writes:
For those times that you want to verify that your readonly filesystem hasn't been tampered we can generate a dm-verity hash table. The root hash is enclosed in .table file and must be secured else where.
Signed-off-by Ben Whitten <[email protected]>
Like we discussed earlier, this is too simplistic/specific, and should be handled in a post-image script.
I've marked this patch as rejected in patchwork.
Signature · 1 line
Bye, Peter Korsgaard