Lines Matching +full:device +full:- +full:tree

2 dm-verity
5 Device-Mapper's "verity" target provides transparent integrity checking of
7 This target is read-only.
21     This is the type of the on-disk hash format.
32     This is the device containing data, the integrity of which needs to be
33     checked.  It may be specified as a path, like /dev/sdaX, or a device number,
37     This is the device that supplies the hash tree data.  It may be
38     specified similarly to the device path and may be the same device.  If the
39     same device is used, the hash_start should be outside the configured
40     dm-verity device.
43     The block size on a data device in bytes.
44     Each block corresponds to one digest on the hash device.
50     The number of data blocks on the data device.  Additional blocks are
55     This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
56     to the root block of the hash tree.
59     The cryptographic hash algorithm used for this device.  This should
87     Panic the device when a corrupted block is discovered. This option is
95     Panic the device when an I/O error is detected. This option is
106     verification fails. Use encoding data from the specified device. This
107     may be the same device where data and hash blocks reside, in which case
111     on the hash device after the hash blocks.
119     is M-N.
122     The number of encoding data blocks on the FEC device. The block size for
123     the FEC device is <data_block_size>.
127     FEC device to the beginning of the encoding data.
130     Verify data blocks only the first time they are read from the data device,
131     rather than every time.  This reduces the overhead of dm-verity so that it
134     data device's content will be detected, not online tampering.
136     Hash blocks are still verified each time they are read from the hash device,
144     the root hash during the creation of the device mapper block device.
167 dm-verity is meant to be set up as part of a verified boot path.  This
169 booting from a known-good device (like a USB drive or CD).
171 When a dm-verity device is configured, it is expected that the caller
173 After instantiation, all hashes will be verified on-demand during
175 tree, the root hash, then the I/O will fail.  This should detect
176 tampering with any data on the device and the hash data.
178 Cryptographic hashes are used to assert the integrity of the device on a
179 per-block basis. This allows for a lightweight hash computation on first read
188 Hash Tree
189 ---------
191 Each node in the tree is a cryptographic hash.  If it is a leaf node, the hash
195 Each entry in the tree is a collection of neighboring nodes that fit in one
197 selected cryptographic digest algorithm.  The hashes are linearly-ordered in
201 The tree looks something like:
216 On-disk format
219 The verity kernel code does not read the verity metadata on-disk header.
221 It is expected that a user-space tool will verify the integrity of the
225 be passed via the kernel command-line in a rooted chain of trust where
226 the command-line is verified.
232 The full specification of kernel parameters and on-disk metadata format
244 Set up a device::
246   # dmsetup create vroot --readonly --table \
252 the hash tree or activate the kernel device. This is available from
256 Create hash on the device::
262 Activate the device::