Talk:Dm-verity

Initial edit

Hi archwiki community... I'm not sure if this goes against guidelines or not but this is my first page on the wiki and I'd like to thank you in advance for taking the time to help make me make it perfect for the wiki. I hope these instructions will help someone else. BluScanDth (talk) 02:57, 3 July 2022 (UTC)

Replace dracut-overlayroot with an alternative

In regards to Section 2.2

I realize not everyone is going to be using dracut and some may not like the solution I created to address the issue of determining which files need to be writable on the read-only root.

If a better solution can be found feel free to replace the link to my project.

Systemd provides systemd-volatile-root.service which does nearly the same thing (it mounts / on a tmpfs in the initramfs at least) but I am unsure if it provides a way to view which files have been written to the tmpfs and it also mounts the /usr part of the tmpfs ro which is not the best use case here.

Dracut's rd.live.overlay is another possible option that would work better out the box than systemd's.

BluScanDth (talk) 07:41, 8 October 2022 (UTC)

How can I update system packages.

Ok, so what I do not get is how I update the "base" system. As root (and /usr, unless I specify it as a different partition) is read-only, I would need to specify a different root for Pacman. I would be looking for something like what rpm-ostree does.

IPlayZed (talk) 14:52, 21 March 2023 (UTC+1)

Hi. This is somewhat outside the scope of the article but I give you two solutions:

1. You can build system images containing all data that should be read-only when system is running. When you update, you make a new images and flash them to the device. (System.ext4.img, Verity.img, EFI.fat32.img, XBOOT.fat32.img). This is reason for suggestion to keep kernels on seperate xboot. You can update bootloader separately with different images.

2. Use an A/B partition layout with two (or more) partitions for '/' and verity. Than when you want to update files from the read-only system (A) you can do 2nd mount of active root (A) under '/mnt' than do an overlay mount with tmpfs upper layer on top of the 2nd root mount. You can then chroot into this new mount point and run pacman or change configs. After you are done you would have to copy all files from the overlay mount to your inactive root partition (B). Also makes it easy to keep track of changed files between update cycles.

For option one you'd need a disk layout that guarantees the sizes and availability of the partitions. You'd basically setup a VM on a 2nd computer and give it an identical partition layout to the target machine. You would install an identical system minus any userdata on this VM and when you want to udpate you'd update the VM and use it create updated partition images you'd then have to load on the target device. I like this because erofs (or squashfs if you're into that) ensures the root stays RO and also reduces size by close to half.

For option two your mount folder would look like this

/mnt

1. /current-root-ro (this is the verity device setup with / and it's verity hash tree)

2. /root-update (writable tmpfs or other filesystem, contains only new or edited files)

3. /root-rw (overlayfs) - overwrites 1 with 2 and appears as one filesystem.

Either way once you update the system you would have to rehash verity and update that partition that as well, and create an updated Unified Kernel Image which contains the new verity root hash in the cmdline. You don't need to edit the contents of '/var' beyond adding in the new files from an update. Option two lets you keep track of what changes in '/var' because the tmpfs mount of the overlay will have a '/var' ONLY containing those files. You can do this with option 1 if you don't mount var on the overlay.

Note systemd has services already that can deploy images to partitions automatically from an update server. For more info see

https://www.freedesktop.org/software/systemd/man/systemd-sysupdate.html

and

https://www.freedesktop.org/software/systemd/man/systemd-repart.html#

It's basically what android does.

Option 1 will be the most secure assuming you take steps to prevent Option 2 and also use tight permissions around write access/mount permissions besides on /home, /var, /tmp, and /run. You could even strip out kernel modules in the UKIs to prevent mounting overlayfs and use sudoers to prevent users from running mkfs, lvm, loop mounts, etc.

BluScanDth (talk) 09:30, 26 March 2023 (UTC)