All of lore.kernel.org
 help / color / mirror / Atom feed
* [Fwd: Re: DM-Verity Tool]
@ 2013-05-31 13:28 pavankumar.p
  2013-06-03 14:29 ` Mikulas Patocka
  0 siblings, 1 reply; 4+ messages in thread
From: pavankumar.p @ 2013-05-31 13:28 UTC (permalink / raw)
  To: Milan Broz, mpatocka, device-mapper development, Marian Csontos

---------------------------- Original Message ----------------------------
Subject: Re: DM-Verity Tool
From:    pavankumar.p@globaledgesoft.com
Date:    Mon, May 27, 2013 9:22 pm
To:      "Milan Broz" <gmazyland@gmail.com>
         mpatocka@redhat.com
         "device-mapper development" <dm-devel@redhat.com>
         "Marian Csontos" <mcsontos@redhat.com>
--------------------------------------------------------------------------

Hello Mikulas,

> By corrupting the image? :) See tests/verity-compat-test in cryptsetup
> tree, it is basic regression test which is simulating both data and hash
> corruption (it just dd random data to know offset and expects failure.)

In tests/verity-compat-test, in the following line
"check_root_hash  512
9de18652fe74edfb9b805aaed72ae2aa48f94333f1ba5c452ac33b1c39325174 $SALT 1
sha256 8388608"

How's the last parameter (hash_offset) calculated? it's hard coded
here(8388608).

Regards,
Pavan


> Hi All,
>
> Thanks a lot for your support. Now I am able to configure verity target
> using both veritysetup & dmsetup.
>
> Regards,
> Pavan
>
>
>>
>> On 05/23/2013 08:41 AM, pavankumar.p@globaledgesoft.com wrote:
>>> 1. What are the difference between configuring a verity target using
>>> dmsetup & veritysetup. Can these be used interchangeably?
>>
>> dmsetup is just low level tool, you need to know all table parameters
>> while veritysetup will prepare table for you using high level commands
>> and on-disk metadata (if present).
>>
>>> 2. I tried passing the root hash value generated by veritysetup as a
>>> parameter to dmsetup but this doesn't work. On doing dmsetup status,
>>> the
>>> output is showing as the target corrupted (C). I examined dmesg & found
>>> the following error
>>
>> Be sure you are using proper parameters, metadata version etc.
>>
>> Try activate device with veritysetup, then run "dmsetup table" and
>> check what is different in your dmsetup line.
>>
>>> 3. After creating a verity target using "veritysetup" how to test the
>>> target for corrupted case (As soon as creating the status is Verified
>>> (V))
>>
>> By corrupting the image? :) See tests/verity-compat-test in cryptsetup
>> tree, it is basic regression test which is simulating both data and hash
>> corruption (it just dd random data to know offset and expects failure.)
>>
>> Milan
>>
>
>

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

* Re: [Fwd: Re: DM-Verity Tool]
  2013-05-31 13:28 [Fwd: Re: DM-Verity Tool] pavankumar.p
@ 2013-06-03 14:29 ` Mikulas Patocka
  2013-06-05 15:59   ` DM-Verity pavankumar.p
  0 siblings, 1 reply; 4+ messages in thread
From: Mikulas Patocka @ 2013-06-03 14:29 UTC (permalink / raw)
  To: pavankumar.p; +Cc: device-mapper development, Marian Csontos, Milan Broz



On Fri, 31 May 2013, pavankumar.p@globaledgesoft.com wrote:

> ---------------------------- Original Message ----------------------------
> Subject: Re: DM-Verity Tool
> From:    pavankumar.p@globaledgesoft.com
> Date:    Mon, May 27, 2013 9:22 pm
> To:      "Milan Broz" <gmazyland@gmail.com>
>          mpatocka@redhat.com
>          "device-mapper development" <dm-devel@redhat.com>
>          "Marian Csontos" <mcsontos@redhat.com>
> --------------------------------------------------------------------------
> 
> Hello Mikulas,
> 
> > By corrupting the image? :) See tests/verity-compat-test in cryptsetup
> > tree, it is basic regression test which is simulating both data and hash
> > corruption (it just dd random data to know offset and expects failure.)
> 
> In tests/verity-compat-test, in the following line
> "check_root_hash  512
> 9de18652fe74edfb9b805aaed72ae2aa48f94333f1ba5c452ac33b1c39325174 $SALT 1
> sha256 8388608"
> 
> How's the last parameter (hash_offset) calculated? it's hard coded
> here(8388608).
> 
> Regards,
> Pavan

If you use two separate devices for data and hash, hash offset is zero 
(hash starts at the beginning of the second device).

If you use one block device for both data and hash, hash offset points to 
the end of the data (and beginning of hash) - if you want to use it this 
way, you have to set hash offset manually.

Mikulas

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

* DM-Verity
  2013-06-03 14:29 ` Mikulas Patocka
@ 2013-06-05 15:59   ` pavankumar.p
  2013-06-06 14:41     ` DM-Verity Will Drewry
  0 siblings, 1 reply; 4+ messages in thread
From: pavankumar.p @ 2013-06-05 15:59 UTC (permalink / raw)
  To: Mikulas Patocka; +Cc: device-mapper development, Marian Csontos, Milan Broz

Hi All,
   I understand that hash generated by "sha256" is encrypted, but is there
any way to corrupt hash value stored in hash device?
Can the hash device be protected by a signature?



Thanks in advance,
Pavan

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

* Re: DM-Verity
  2013-06-05 15:59   ` DM-Verity pavankumar.p
@ 2013-06-06 14:41     ` Will Drewry
  0 siblings, 0 replies; 4+ messages in thread
From: Will Drewry @ 2013-06-06 14:41 UTC (permalink / raw)
  To: device-mapper development; +Cc: Marian Csontos, Mikulas Patocka, Milan Broz

Hi Pavan,

I think there's a bit of a mismatch in the terminology that you're
using.  I'll try to help:

On Wed, Jun 5, 2013 at 10:59 AM,  <pavankumar.p@globaledgesoft.com> wrote:
> Hi All,
>    I understand that hash generated by "sha256" is encrypted,

sha256 is a type of cryptographic hash algorithm.  It is a one-way
transformation of some data.  In this case, the hash isn't encrypted,
it just has desirable properties when acting as a strong checksum over
some dataset.

The hash passed in during setup (for the table) is the root hash of a
hash tree (also called Merkle Trees).  It is a checksum over the depth
below it in the tree which in turn is a checksum over the depth below
it, until the leaf nodes on the tree are the blocks-on-disk
themselves.  The self-checked tree structure provides transitive
integrity assurances verifiable at any time if you have the full data
set and the root hash.  It is possible to allow partial verification
of any path through the tree if the nodes along the path from the leaf
to the root are precomputed and made available.  dm-verity takes
advantage of this property to provide high performance integrity
assurances.

> but is there any way to corrupt hash value stored in hash device?

The hash tree that lives on the hash device is completely untrusted.
The hash tree can easily be corrupted with 'dd' just like with the
data device. If the hash tree is corrupted, dm-verity will fail to
verify the data because it will be unable to create a verifiable path
through the hash tree from the block to the root hash that was passed
in at device setup.

> Can the hash device be protected by a signature?

Generally, you will want to protect the dm-verity table line with a
signature and not the hash device itself.  At any point you can
recompute the hash device with veritysetup.  However, the "root of
trust" for a dm-verity device is always the hash passed in during
device mapper setup.  It is ideal, then, to ensure that the hash value
and device settings are always what was expected when the dm-verity
device was created or last updated.


I hope that helps,
will

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

end of thread, other threads:[~2013-06-06 14:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-31 13:28 [Fwd: Re: DM-Verity Tool] pavankumar.p
2013-06-03 14:29 ` Mikulas Patocka
2013-06-05 15:59   ` DM-Verity pavankumar.p
2013-06-06 14:41     ` DM-Verity Will Drewry

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.