Lines Matching refs:the

5 block devices using a cryptographic digest provided by the kernel crypto API.
17     This is the type of the on-disk hash format.
19     0 is the original format used in the Chromium OS.
21       the rest of the block is padded with zeros.
23     1 is the current format that should be used for new devices.
25       padded with zeros to the power of two.
28     This is the device containing data, the integrity of which needs to be
33     This is the device that supplies the hash tree data.  It may be
34     specified similarly to the device path and may be the same device.  If the
35     same device is used, the hash_start should be outside the configured
40     Each block corresponds to one digest on the hash device.
46     The number of data blocks on the data device.  Additional blocks are
47     inaccessible.  You can place hashes to the same partition as data, in this
51     This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
52     to the root block of the hash tree.
56     be the name of the algorithm, like "sha1".
59     The hexadecimal encoding of the cryptographic hash of the root hash block
60     and the salt.  This hash should be trusted as there is no other authenticity
64     The hexadecimal encoding of the salt value.
68     the optional paramaters section can be skipped or #opt_params can be zero.
69     Otherwise #opt_params is the number of following arguments.
78     Restart the system when a corrupted block is discovered. This option is
89 When a dm-verity device is configured, it is expected that the caller
92 disk access.  If they cannot be verified up to the root node of the
93 tree, the root hash, then the I/O will fail.  This should detect
94 tampering with any data on the device and the hash data.
96 Cryptographic hashes are used to assert the integrity of the device on a
98 into the page cache. Block hashes are stored linearly, aligned to the nearest
104 Each node in the tree is a cryptographic hash.  If it is a leaf node, the hash
106 the hash of a number of child nodes is calculated.
108 Each entry in the tree is a collection of neighboring nodes that fit in one
109 block.  The number is determined based on block_size and the size of the
112 calculating the parent node.
130 The verity kernel code does not read the verity metadata on-disk header.
131 It only reads the hash blocks which directly follow the header.
132 It is expected that a user-space tool will verify the integrity of the
135 Alternatively, the header can be omitted and the dmsetup parameters can
136 be passed via the kernel command-line in a rooted chain of trust where
137 the command-line is verified.
139 Directly following the header (and with sector number padded to the next hash
140 block boundary) are the hash blocks which are stored a depth at a time
141 (starting from the root), sorted in order of increasing index.
144 is available at the cryptsetup project's wiki page
161 the hash tree or activate the kernel device. This is available from
162 the cryptsetup upstream repository https://gitlab.com/cryptsetup/cryptsetup/
165 Create hash on the device:
170 Activate the device: