libmount: add support for verity devices via libcryptsetup #898

bluca · 2019-11-15T15:29:06Z

The following new options are added:

verity.hashdevice
verity.roothash
verity.hashoffset

The source path will be used as a dm-verity object, and will be
opened using libcryptsetup APIs.

A new --with-cryptsetup build-time option is added, which adds a
dependency on libcryptsetup.

bluca · 2019-11-15T15:50:42Z

Ah, got it: it's because of the optimization to avoid reading /proc/self/mountinfo at: https://github.com/karelzak/util-linux/blob/master/libmount/src/context_umount.c#L264

If I add --force to bypass it, it works.

bluca · 2019-11-15T17:21:21Z

Any suggestion on how to handle this? I'll look into dm-uuid on Monday

karelzak · 2019-11-18T09:51:09Z

Any suggestion on how to handle this? I'll look into dm-uuid on Monday

For loop devices we have autoclear flag -- it means that after last umount kernel automatically detach the device. The same is possible by deferred deactivation for DM. All you need is to call:

   crypt_deactivate_by_name(dev, name, CRYPT_DEACTIVATE_DEFERRED)

(see mbroz/cryptsetup@32d5e59, thanks @mbroz for this hint)

after successful filesystem mount. So, you need to add this call to the end of the function mnt_context_do_mount() -- maybe introduce mnt_context_veritydev_post_mount() (or so) to keep all in context_veritydev.c.

It also means that in umount code you do not have to care about dm-verity at all :-)

bluca · 2019-11-18T09:56:51Z

Brilliant, I had missed that DM had the same feature, thanks! I'll have time to work on that tomorrow and then I'll push a new version.

bluca · 2019-11-19T20:22:10Z

@karelzak it's working great, thanks for the tip!
With the latest update the basics are working - auto cleanup on umount, or on failed mount.

TODO: documentation, testing, device reuse, make the hashoffset an alternative to the inline hash, possibly more options

bluca · 2019-11-20T16:46:06Z

hash offset is now used, and a naive device reuse is also implemented. I need to make it a bit more complex and check that the root hash is actually the same, otherwise by simply looking at the mapper name one could be "tricked" in using a different backing device than intended.

karelzak · 2019-12-03T12:11:01Z

Are we ready to merge it? I'd like to release the next -rc1 (next week).

bluca · 2019-12-03T14:56:51Z

@karelzak I am happy with the current implementation I've just pushed: the device is reused when the user passes the same volume multiple times, as long as the root hashes match and if libcryptsetup supports extracting the root hash from an existing mounted volume in the first place. It does not out right now, and I'd rather not implement it manually messing with libdevmapper as it complicates things quite a bit. I have sent a PR upstream to support this, it seems trivial to do on the surface and it matches how the API is used in other places: https://gitlab.com/cryptsetup/cryptsetup/merge_requests/72

If cryptsetup does not support this use case, reusing the same device is not allowed. A user that is sure of what they are doing can simply mount the mapper device directly, or bind mount the target. If cryptsetup's upstream rejects the patch, I could implement randomization of the mapper device naming in case of clashes to support the use case, but re-using seems nicer and I'd rather go with it if possible. What do you think?

I have updated the mount.8 manpage, and the python constants with the new options. Still need to look into unit tests.

Here's a few manual runs with and without the updated cryptsetup:

$ sudo LIBMOUNT_DEBUG=options,loop,verity LD_LIBRARY_PATH=$PWD/.libs .libs/mount -v -o verity.hashdevice=/tmp/testimage.hashtree,verity.roothash=e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943d /tmp/testimage.squashfs /tmp/img
31039: libmount:     INIT: library debug mask: 0x600a
31039: libmount:     INIT: library version: 2.34.337
31039: libmount:     INIT:     feature: btrfs
31039: libmount:     INIT:     feature: namespaces
31039: libmount:     INIT:     feature: assert
31039: libmount:     INIT:     feature: debug
31039: libmount:   VERITY: [0x55987885fa60]: veritydev specific options detected
31039: libmount:   VERITY: [0x55987885fa60]: trying to setup verity device for /tmp/testimage.squashfs
31039: libmount:   VERITY: [0x55987885fa60]: veritydev specific options detected
31039: libmount:   VERITY: [0x55987885fa60]: deleted [rc=0]
mount: /dev/mapper/libmnt_testimage.squashfs mounted on /tmp/img.
$ sudo LIBMOUNT_DEBUG=options,loop,verity LD_LIBRARY_PATH=$PWD/.libs .libs/mount -v -o verity.hashdevice=/tmp/testimage.hashtree,verity.roothash=e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943d /tmp/testimage.squashfs /tmp/test
31056: libmount:     INIT: library debug mask: 0x600a
31056: libmount:     INIT: library version: 2.34.337
31056: libmount:     INIT:     feature: btrfs
31056: libmount:     INIT:     feature: namespaces
31056: libmount:     INIT:     feature: assert
31056: libmount:     INIT:     feature: debug
31056: libmount:   VERITY: [0x564b016dca60]: veritydev specific options detected
31056: libmount:   VERITY: [0x564b016dca60]: trying to setup verity device for /tmp/testimage.squashfs
Device libmnt_testimage.squashfs already exists.
31056: libmount:   VERITY: [0x564b016dca60]: /tmp/testimage.squashfs already in use as /dev/mapper/libmnt_testimage.squashfs
31056: libmount:   VERITY: [0x564b016dca60]: libcryptsetup does not support extracting root hash of existing device
mount: /tmp/test: mount failed: File exists.
$ sudo LIBMOUNT_DEBUG=options,loop,verity LD_LIBRARY_PATH=$PWD/.libs:$PWD/../cryptsetup/.libs .libs/mount -v -o verity.hashdevice=/tmp/testimage.hashtree,verity.roothash=e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943d /tmp/testimage.squashfs /tmp/test
31066: libmount:     INIT: library debug mask: 0x600a
31066: libmount:     INIT: library version: 2.34.337
31066: libmount:     INIT:     feature: btrfs
31066: libmount:     INIT:     feature: namespaces
31066: libmount:     INIT:     feature: assert
31066: libmount:     INIT:     feature: debug
31066: libmount:   VERITY: [0x56342cd01a60]: veritydev specific options detected
31066: libmount:   VERITY: [0x56342cd01a60]: trying to setup verity device for /tmp/testimage.squashfs
Device libmnt_testimage.squashfs already exists.
31066: libmount:   VERITY: [0x56342cd01a60]: /tmp/testimage.squashfs already in use as /dev/mapper/libmnt_testimage.squashfs
31066: libmount:   VERITY: [0x56342cd01a60]: comparing root hash of existing device with e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943d
31066: libmount:   VERITY: [0x56342cd01a60]: root hash of libmnt_testimage.squashfs matches e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943d, reusing device
31066: libmount:   VERITY: [0x56342cd01a60]: veritydev specific options detected
31066: libmount:   VERITY: [0x56342cd01a60]: deleted [rc=0]
mount: /dev/mapper/libmnt_testimage.squashfs mounted on /tmp/test.
$ sudo umount /tmp/test
$ sudo LIBMOUNT_DEBUG=options,loop,verity LD_LIBRARY_PATH=$PWD/.libs:$PWD/../cryptsetup/.libs .libs/mount -v -o verity.hashdevice=/tmp/testimage.hashtree,verity.roothash=e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943e /tmp/testimage.squashfs /tmp/test
31080: libmount:     INIT: library debug mask: 0x600a
31080: libmount:     INIT: library version: 2.34.337
31080: libmount:     INIT:     feature: btrfs
31080: libmount:     INIT:     feature: namespaces
31080: libmount:     INIT:     feature: assert
31080: libmount:     INIT:     feature: debug
31080: libmount:   VERITY: [0x55f976135a60]: veritydev specific options detected
31080: libmount:   VERITY: [0x55f976135a60]: trying to setup verity device for /tmp/testimage.squashfs
Device libmnt_testimage.squashfs already exists.
31080: libmount:   VERITY: [0x55f976135a60]: /tmp/testimage.squashfs already in use as /dev/mapper/libmnt_testimage.squashfs
31080: libmount:   VERITY: [0x55f976135a60]: comparing root hash of existing device with e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943e
31080: libmount:   VERITY: [0x55f976135a60]: existing device's hash does not match with e21abeb91ef65c777922f01e78ae9e6f1cca0ef6a0893907d05847acdbe6943e
mount: /tmp/test: mount failed: Invalid argument.

(the last mount passes a wrong root hash)

The following new options are added: verity.hashdevice verity.roothash verity.hashoffset The source path will be used as a dm-verity object, and will be opened using libcryptsetup APIs. A new --with-cryptsetup build-time option is added, which adds a dependency on libcryptsetup. To ease bootstrapping, given libcryptsetup build-depends on util-linux for libuuid, if --with-cryptsetup=yes but libcryptsetup is not installed only a warning will be printed at configure time rather than an error. This way stage0/first stage/ring0 builds can use the same configure options but avoid installing cryptsetup to get a working base set, and then rebuild util-linux in the next step of the boostrapping process. If verity options are selected but cannot be fullfilled due to lack of dependencies, mounting a volume will fail even if using a loop device would work as a fallback, to avoid silently skipping integrity checks.

bluca · 2019-12-05T10:53:33Z

Pushed a small revision for the case where libcryptsetup is not selected or not available:

instead of silently falling back to loopdev without integrity checks, if verity options are requested the mount will fail (and appropriate debug messages are printed)
if --with-cryptsetup is set but libcryptsetup is not available at build time only a warning will be printed, rather than erroring out

cryptsetup build-depends on util-linux for libblkid (optional, can be disabled) and libuuid (mandatory) - this causes a circular dependency. The --with-cryptsetup change allows to break it, by letting maintainers to re-use the exact same build options but with different build environments.
In practice, for Debian/Ubuntu the libcryptsetup-dev build-dependency would be marked with the <!stage1> profile, so that the first pass builds without this and allows cryptsetup to be built. The second stage build can then bring this in. The util-linux package already does this for a variety of optional build-deps of util-linux like libaudit and libsystemd, see: https://tracker.debian.org/media/packages/u/util-linux/control-2.34-0.1

For SUSE the inner ring build prjconf could have Ignore: util-linux:cryptsetup to achieve the same result. Or the spec file could be duplicated and ran in different stages, as it's done right now for util-linux-libsystemd.
Not sure how RHEL/Fedora handle bootstrapping, but I assume this will be useful in a similar way.

karelzak · 2019-12-05T12:23:08Z

Thanks for --with-cryptsetup. I plan to keep it disabled by default for the first release, in the next releases it would be probably better to enable it automatically if the devel cryptsetup libs are installed (just set [with_cryptsetup=auto]). Going to merge it and test it :-)

bluca · 2019-12-05T14:16:39Z

Thank you! Let me know if I can help further.

If the libcryptsetup bits about root hash signature are merged (new feature in kernel 5.5), I'll send at least one further PR to add the corresponding option.

karelzak · 2019-12-05T14:34:54Z

Merged. Thanks! Good work.

I did a small change to the mount.8 man page to explain it better and to add an example. Now we need regression tests ;-)

bluca · 2019-12-05T15:00:23Z

Yes, I wanted to give unit tests a go but ran out of time to figure out how the local test framework unfortunately - if you could give me some quick pointers to get up and running I can try to find time to give it a go

karelzak · 2019-12-05T19:10:40Z

Don't worry, I'm going to write the test. It seems pretty simple :-)

Thanks for all the time you invest to this feature.

In v2.35 util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. Add a packageconfig switch (disabled by default) to allow using the new dependency. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In v2.35 util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. Add a packageconfig switch (disabled by default) to allow using the new dependency. util-linux/util-linux#898 (From OE-Core rev: 94d572cf59a47ad082c948064b092f8ed0a63ca0) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: b8826ee1689222ac8a7035179dd19ac54a489b55) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: 0463c35f8e3f571b9dcc7bed2f276011c15ed9c3) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: 9f2636bbf574a4bce940ff4d0ce17da5dbc5870b) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: baef93bef78f327723f993e9bba33f404e5f59bb) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: e781046f2f0f1549de08384a0fb5283c1e13f7a4) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recently util-linux gained an (optional) build dependency on libcryptsetup. But libcryptsetup build-depends on util-linux for blkid (optional, can be disabled) and uuid (mandatory). Split out util-linux-uuid in a different recipe to break the cycle. util-linux/util-linux#898 (From OE-Core rev: 5f204796e73f37ee67d0a86512ce3ab6f19f9ed0) Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bluca force-pushed the dmverity branch 2 times, most recently from ab57ccc to 6109c31 Compare November 15, 2019 15:49

bluca mentioned this pull request Nov 15, 2019

Mount units: add native support for dm-verity systemd/systemd#13471

Closed

bluca force-pushed the dmverity branch 4 times, most recently from 251c72f to 1ce9cff Compare November 19, 2019 20:19

bluca force-pushed the dmverity branch from 1ce9cff to 0885239 Compare November 20, 2019 16:44

bluca force-pushed the dmverity branch from 0885239 to 639ec63 Compare November 21, 2019 15:51

bluca force-pushed the dmverity branch 2 times, most recently from f6a092f to fad952b Compare December 3, 2019 14:45

bluca changed the title ~~[RFC WIP] libmount: add support for verity devices via libcryptsetup~~ [RFC] libmount: add support for verity devices via libcryptsetup Dec 3, 2019

bluca force-pushed the dmverity branch from fad952b to 1b193c0 Compare December 3, 2019 15:42

bluca changed the title ~~[RFC] libmount: add support for verity devices via libcryptsetup~~ libmount: add support for verity devices via libcryptsetup Dec 3, 2019

bluca force-pushed the dmverity branch from 1b193c0 to e6a4988 Compare December 5, 2019 10:43

karelzak merged commit e6a4988 into util-linux:master Dec 5, 2019

bluca deleted the dmverity branch December 5, 2019 14:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

libmount: add support for verity devices via libcryptsetup #898

libmount: add support for verity devices via libcryptsetup #898

bluca commented Nov 15, 2019 •

edited

bluca commented Nov 15, 2019

bluca commented Nov 15, 2019

karelzak commented Nov 18, 2019

bluca commented Nov 18, 2019

bluca commented Nov 19, 2019

bluca commented Nov 20, 2019

karelzak commented Dec 3, 2019

bluca commented Dec 3, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

libmount: add support for verity devices via libcryptsetup #898

libmount: add support for verity devices via libcryptsetup #898

Conversation

bluca commented Nov 15, 2019 • edited

bluca commented Nov 15, 2019

bluca commented Nov 15, 2019

karelzak commented Nov 18, 2019

bluca commented Nov 18, 2019

bluca commented Nov 19, 2019

bluca commented Nov 20, 2019

karelzak commented Dec 3, 2019

bluca commented Dec 3, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

bluca commented Dec 5, 2019

karelzak commented Dec 5, 2019

bluca commented Nov 15, 2019 •

edited