On 06/11/2012 08:08 PM, .. ink .. wrote: >> veritysetup format <data_device> <hash_device> >> Formats <hash_device> (calculates all hash areas according to <data_device>). >> This is initial command to prepare device <hash_device> for later verification. >> > > I just cruised over mentioned docs and didnt find an answer.The only > thing i saw is that <data_device> and <hash_device> can be in the same > device in the DMVerify wiki page but nothing about relative sizes. Documentation is just part take form kernel doc, see also former patches on dm-devel from Google https://www.redhat.com/archives/dm-devel/2012-March/msg00003.html The kernel part was rewritten later though. (I will perhaps add more info to wiki later...) I just integrated existing code to cryptsetup (well, it means another rewrite of userspace:-) So, for shared device, it can be like this: |-------------device----------------| | -verified data- | |SB| -hash area-| ^ ^ | --data blocks--| | offset provided to kernel superblock offset So if you want to store both hash and data on the same device, you have to provide --data-blocks and --hash-offset for format. (For verify and create --hash-offset is enough because data blocks number is stored inside superblock.) Also --no-superblock option can be used, then it needs to specify all parameters (it is like "plain" device vs LUKS in cryptsetup). For device sizes: - data blocks describes size of verified area (usually the whole device). So it is either provided by user, or it is calculated from the whole device size (data_blocks = device_size / data_block_size) - hash device size is calculated during format, currently it is visible when you run it in debug mode (perhaps the API will be extended later to get this directly, dunno yet.) > Does the <hash_device> need to be the same size as <data device> ? If > not, does the space taken by <hash_device> grow as some sort of a > function to the size of <data_device>? Yes. Obviously, hash area is smaller than data area (one hash, typically 32 bytes, verifies one data block which is by default 4096 bytes + you need space for tree hash structure etc). Try to run format with --debug on some testing device and you will see a lot of info what it is doing, for example in release notes mail: ... # Hash creation sha256, data device /dev/sdb, data blocks 52224, hash_device /dev/sdc, offset 1. # Using 3 hash levels. # Data device size required: 213909504 bytes. # Hash device size required: 1695744 bytes. # Updating VERITY header of size 512 on device /dev/sdc, offset 0. VERITY header information for /dev/sdc UUID: b415461f-93d3-4e3d-a5ef-3c3aa8b3686c Hash type: 1 Data blocks: 52224 Data block size: 4096 Hash block size: 4096 Hash algorithm: sha256 >> veritysetup create <name> <data_device> <hash_device> <root_hash> > > Does this mean a user will have to store the <root_hash> generated in > the formatting stage and supply it everytime a mapper is created? Is > the <root_hash> supposed to be a secret? Yes, root hash must be supplied every time and must be trusted. It is not secret - you can calculate hash yourself (that's exactly what verification does - compares own calculated hash with stored value, from leaf nodes to root level and, finally, compares with trusted root hash.) (So if is used to implementation of "trusted" boot, root hash should be signed, stored in some trusted read-only device, whatever.) (I guess dm-verity can be used in some special environments, it is perhaps not something widely usable. If you ask about GUI - no, I do not think there is some need for it;-) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
