New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

investigate dm-verity backend #853

Open
cgwalters opened this Issue May 11, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@cgwalters
Member

cgwalters commented May 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Jun 21, 2017

Member

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.

Member

cgwalters commented Jun 21, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment