cryptsetup.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* dm-verity setup on loop device
@ 2022-04-07  9:40 Jasper Surmont
  2022-04-07 10:05 ` Milan Broz
  0 siblings, 1 reply; 4+ messages in thread
From: Jasper Surmont @ 2022-04-07  9:40 UTC (permalink / raw)
  To: cryptsetup

Dear,

While trying to understand the dm-verity code, I tried making a small
verity setup. I created 1 readonly loop device and 1 non-readonly loop
device. When I then try to create the verity target with the readonly
as data device (not using veritysetup because I want to experiment on
a low level), dmesg still says that the device is not in readonly
mode.

Is it possible what I'm trying to achieve?
If so, what am I doing wrong?

Thanks! Regards Jasper

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: dm-verity setup on loop device
  2022-04-07  9:40 dm-verity setup on loop device Jasper Surmont
@ 2022-04-07 10:05 ` Milan Broz
  2022-04-07 11:42   ` Jasper Surmont
  0 siblings, 1 reply; 4+ messages in thread
From: Milan Broz @ 2022-04-07 10:05 UTC (permalink / raw)
  To: Jasper Surmont, cryptsetup

On 07/04/2022 11:40, Jasper Surmont wrote:
> While trying to understand the dm-verity code, I tried making a small
> verity setup. I created 1 readonly loop device and 1 non-readonly loop
> device. When I then try to create the verity target with the readonly
> as data device (not using veritysetup because I want to experiment on
> a low level), dmesg still says that the device is not in readonly
> mode.
> 
> Is it possible what I'm trying to achieve?

Yes, it should be possible.
(If you have device with Merkle-tree already prepared, if not, it will only
activate in failed state - but it will allow creation of the DM device.)

And if you post the exact command you are trying,
maybe we can show you where is the problem :-)

Both devices should be read only (dm-verity cannot be mapped for writes)
and I guess you need to call dmsetup with -r (--readonly) option.

Milan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: dm-verity setup on loop device
  2022-04-07 10:05 ` Milan Broz
@ 2022-04-07 11:42   ` Jasper Surmont
  2022-04-07 12:15     ` Milan Broz
  0 siblings, 1 reply; 4+ messages in thread
From: Jasper Surmont @ 2022-04-07 11:42 UTC (permalink / raw)
  To: cryptsetup

Hey,

Thanks, I didn't realise you also had to use the -r flag with dmsetup.

I've got a few more questions concerning dm-verity:

- dm-verity itself (not veritysetup or any userspace programs) expects
a full merkle tree to be built and the corresponding root hash to be
passed as an argument. I saw in the source code that the constructor
will verify the root hash using the sig if enabled, but does it also
check whether the root hash is correct concerning the hash tree? i.e.
Does it traverse the tree to check if the given root hash is correct?
I don't think so, but since there is quite a lot of code I might be
missing something.

- The documentation states: After instantiation, all hashes will be
verified on-demand during disk access. This means that the hashes will
be verified on every read to any block on the data device right?

- If the previous answer is yes; where is the actual verification of
the hashes done? I see a lot of functions with '_prefetch' and I know
what prefetch is, but it's all a bit confusing to me.

Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: dm-verity setup on loop device
  2022-04-07 11:42   ` Jasper Surmont
@ 2022-04-07 12:15     ` Milan Broz
  0 siblings, 0 replies; 4+ messages in thread
From: Milan Broz @ 2022-04-07 12:15 UTC (permalink / raw)
  To: cryptsetup

On 07/04/2022 13:42, Jasper Surmont wrote:
> Hey,
> 
> Thanks, I didn't realise you also had to use the -r flag with dmsetup.
> 
> I've got a few more questions concerning dm-verity:
> 
> - dm-verity itself (not veritysetup or any userspace programs) expects
> a full merkle tree to be built and the corresponding root hash to be
> passed as an argument. I saw in the source code that the constructor
> will verify the root hash using the sig if enabled, but does it also
> check whether the root hash is correct concerning the hash tree? i.e.
> Does it traverse the tree to check if the given root hash is correct?
> I don't think so, but since there is quite a lot of code I might be
> missing something.

Best read Google design doc for Android, I think that is where you aiming
at anyway :)

DM mapping table need to receive a correct root hash, I think incorrect
format is the only situation when the device is marked invalid immediatelly
(see dmsetup status).

The verification is then run according to reads of the device - once a read
comes, the path in Merkle tree (up to the root) is verified.

And in normal situation reads come immediately after activation - because
udev initiates scan of the device for known signatures (blkid).

There are several optional performance optimizations, though, like ignoring
empty sectors (ignore_zero_blocks) or to cache verification (check_at_most_once)
see https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity
(I do not like it, as it allows some attacks with switching underlying device
content, but Google apparently need it for Android.)

So it depends on configuration, but for default, everything should be
checked on every read up to the Merkle root hash.

> - The documentation states: After instantiation, all hashes will be
> verified on-demand during disk access. This means that the hashes will
> be verified on every read to any block on the data device right?

Yes, see above. There is page cache above the block device, so not
everything propagates to dm-verity repeatedly.

BTW there is one special case, when device is so small, that only root
hash is present (then the hash device contains only header).

> - If the previous answer is yes; where is the actual verification of
> the hashes done? I see a lot of functions with '_prefetch' and I know
> what prefetch is, but it's all a bit confusing to me.

In normal situation it is directly in kernel dm-verity kernel module.
And it *is* complex... You have read the code here.

You can also run test verification in userspace with veritysetup command
(good for testing injected data corruption).
Android has own tooling, but veritysetup should be compatible with images
created by Adnroid tools (including additional metadata areas we do not use).

Milan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-04-07 12:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-07  9:40 dm-verity setup on loop device Jasper Surmont
2022-04-07 10:05 ` Milan Broz
2022-04-07 11:42   ` Jasper Surmont
2022-04-07 12:15     ` Milan Broz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).