Please add requirements:

• Use case?
• Which hashes?
• What should be checked?

I'd like it to function very similar to Fedora's, where, on boot, it goes through something like "Verifying checksums... 0% (Press Esc to cancel)"

This would only be done on the live image, and would function the same as selecting the boot entry (on BIOS I think?)

Does that help?

Also, @teward has more experience with this, but once we get something working, we need a systemd unit (again, probably mirrored after Fedora's) and some packaging (which I can handle).

@tsimonq2 I'm not sure we have the mechanism to create an interruptible SystemD unit like that. Will have to look into it.

@tsimonq2 I think you've still ignored some of the question asked:

WHICH checksums/hashes? What are the defacto 'standard' hashes that we want to check against? What files and such do we *actually* check?

Without these details you can't even begin to create a hash checking system to do what you want, SystemD issues aside.

and would function the same as selecting the boot entry (on BIOS I think?)

All of the details are here.

Hooooooooooooooooooooooooooooooooold up. Doesn't "check disc for defects" ultimately accomplish the same purpose, except that the user is not forced to run it? Couldn't we build that into the GRUB entry for loading the image, i.e. it would first check for defects and then boot the image?

If not, the squashfs is just a fraction of the iso, so we don't actually have hashes for it. We'd have to build our own. Not a huge deal, but in an ideal world, that would be automated.

You hit the nail on the head @wxl :)

This sounds like something that dm-verity would be ideal for. It is for read-only devices and uses a kernel layer to ensure the block device reads match the hashes.

Adding a dm-verity layer over the top of the squashfs would seem to be the obvious way to do it.

Then I'd suspect all you need is a system service that monitors for failures and notifies the operator..

Adding a link to a very detailed guide to using dm-verity.

https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity

@Tj I'd like to bump this and get some further feedback from you/others on how to go about this.

My understanding is that at this point, we'd have to modify how the squashfs is mounted, use the hash list generated during ISO generation, and enable FEC. I'll admit to not being intimately familiar with this part of the ISO boot process, but my current understanding is that this would have to be part of casper/the initramfs.

My current questions are:

1. Is there noticeable overhead for taking this approach?
2. How do we test if this is working as intended?

This does sound like the way forward, though.

I've been doing some proof-of-concept work recently but currently cannot experiment with FEC because the Ubuntu kernels aren't being built with FEC enabled. I'm going to chase apw on this one.

My bug report about FEC includes all the commands I use to prepare (format) and create the verity-protected device

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838844

Judging by recent conversations on the ubuntu-devel list, it's quite possible this will get implemented without us.

I replied to the ubuntu-devel list but its held in moderation queue currently. If a list moderator is known and can be poked that might help.

I pointed to the dm-verity option and what currently prevents it using FEC.