investigate dm-verity backend

[cgwalters]

One of the important properties of libostree is that it's intended to support every use case covered by package systems (dpkg/rpm/etc) today. Independence of the block layer is critical for this. For example, just like today one can take a set of RPMs and install them on a dm-crypt device, a plain ext4 partition, xfs+lvm, etc - one can do the same with libostree.

The flexibility inherent in being file based is one of the crucial things that allows rpm-ostree to do per-client layering, which in turn helps libostree work both in "single/small-scale" scenarios where one takes a base layer and adds packages per machine, and it also provides atomic updates even for scale out scenarios.

However, on bare metal, and in particular devices where one doesn't want to support extensive configuration (e.g. /etc would be read-only, and the app config would live in /var/app or so), having a libostree backend that instead used dm-verity could be interesting.

I'm not sure offhand how much this would make sense versus a new project that happened to share code (or really, just using the chromeos updater as it exists today).

But could we get to a point where one could take an ostree commit (or a tarball or whatever), and deploy it as either the existing libostree or dm-verity backend? I think the answer is: no, in the sense it doesn't make sense to do per-client. An organization wanting this would need to run a "verity generator server" that took the user's kickstart (partition config) plus ostree, and acted a signing server.
Or of course, just consumed RPMs/debs/git or whatever and constructed the image in a single go.

[cgwalters]

Longer blog on this: https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/ See also LWN discussion: https://lwn.net/Articles/725860/

Basically, I think dm-verity is really only worth it when doing true "appliance" devices, where all of the privileged code is sealed. I'm still not sure what the role of ostree would be here; either on the client or server. As I mentioned in the blog, I could imagine something like taking a Fedora Atomic Host ostree commit, doing some config, adding containers, and then a tool seals all of that up with dm-verity.

But what I am still unclear on is whether it's worth trying to wrap this model with libostree or not vs the chromeos updater.

[cjao]

Something like this would not be practical today because ostree is typically used in both client and server roles. But it could make sense if you use ostree only on the server side to efficiently store a repository of OS images and deploy the image to the client using a different technology. For example, Google snapshots filesystem images in its VCS but basically rsyncs the files to the actual servers.

Just as end users don't typically install applications using git but rather download a tarball, RPM/DEB package, or Windows MSI installer, one can imagine clients consuming release artifacts published from an ostree repo without directly using ostree. A dm-verity image could well be one of those artifacts. A qcow image could be another.

[cjao]

But I guess this is where such a backend would belong these days.