On 9/7/20 10:35 AM, Bartosz Golaszewski wrote:
On Mon, Sep 7, 2020 at 7:17 PM Niko Mauno <niko.mauno@...> wrote:
This set of patches addresses some small issues in dm-verity rootfsHi Niko,
facility, which were observed while making use of dm-verity-img.bbclass
to generate dm-verity rootfs images for real arm-based hardware. For
purposes of establishing this changeset, the default 'qemux86-64'
machine was used as a reference.
During testing/development the following additional settings were
defined in local.conf:
DM_VERITY_IMAGE = "core-image-minimal"
DM_VERITY_IMAGE_TYPE = "ext4"
IMAGE_CLASSES += "dm-verity-img"
INITRAMFS_IMAGE_BUNDLE = "1"
INITRAMFS_IMAGE = "dm-verity-image-initramfs"
And the following command line was used to test the changes with qemu:
qemuparams="-nic none" \
Niko Mauno (6):
dm-verity-img.bbclass: Fix bashisms
dm-verity-img.bbclass: Reorder parse-time check
dm-verity-image-initramfs: Fix do_rootfs dependency
dm-verity-image-initramfs: Ensure verity hash sync
dm-verity-image-initramfs: Bind at do_image instead
linux-yocto(-dev): Add dm-verity fragment as needed
classes/dm-verity-img.bbclass | 12 ++++++------
recipes-core/images/dm-verity-image-initramfs.bb | 7 +++++--
recipes-kernel/linux/linux-yocto-dev.bbappend | 1 +
recipes-kernel/linux/linux-yocto_5.%.bbappend | 1 +
4 files changed, 13 insertions(+), 8 deletions(-)
I saw these patches and had to double-check just to realize my
dm-verity patches actually got upstream to meta-security although I
explicitly stated in the cover letter that they don't work with
verified boot (which basically makes dm-verity useless).
I suspect It didn't register. In the end it did have a silver lining as
it was work that could be leveraged. This is on the core values of open
It's funny you sent them now because I just started working on a
different approach that won't require the OE-core changes I posted a
while ago and which were never merged because they broke some unit
Niko: do your changes allow this to work with verified boot on BeagleBone Black?