Lines Matching full:of

5 Device-Mapper's "verity" target provides transparent integrity checking of
21     This is the type of the on-disk hash format.
25       the rest of the block is padded with zeroes.
29       padded with zeroes to the power of two.
32     This is the device containing data, the integrity of which needs to be
47     The size of a hash block in bytes.
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.
60     be the name of the algorithm, like "sha1".
63     The hexadecimal encoding of the cryptographic hash of the root hash block
68     The hexadecimal encoding of the salt value.
71     Number of optional parameters. If there are no optional parameters,
73     Otherwise #opt_params is the number of following arguments.
75     Example of optional parameters section:
108     Number of generator roots. This equals to the number of parity bytes in
109     the encoding data. For example, in RS(M, N) encoding, the number of roots
113     The number of encoding data blocks on the FEC device. The block size for
117     This is the offset, in <data_block_size> blocks, from the start of the
118     FEC device to the beginning of the encoding data.
122     rather than every time.  This reduces the overhead of dm-verity so that it
124     provides a reduced level of security because only offline tampering of the
128     since verification of hash blocks is less performance critical than data
133     This is the description of the USER_KEY that the kernel will lookup to get
134     the pkcs7 signature of the roothash. The pkcs7 signature is used to validate
135     the root hash during the creation of the device mapper block device.
136     Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG
139 Theory of operation
142 dm-verity is meant to be set up as part of a verified boot path.  This
149 disk access.  If they cannot be verified up to the root node of the
153 Cryptographic hashes are used to assert the integrity of the device on a
158 If forward error correction (FEC) support is enabled any recovery of
159 corrupted data will be verified using the cryptographic hash of the
167 of some data block on disk is calculated. If it is an intermediary node,
168 the hash of a number of child nodes is calculated.
170 Each entry in the tree is a collection of neighboring nodes that fit in one
171 block.  The number is determined based on block_size and the size of the
196 It is expected that a user-space tool will verify the integrity of the
200 be passed via the kernel command-line in a rooted chain of trust where
205 (starting from the root), sorted in order of increasing index.
207 The full specification of kernel parameters and on-disk metadata format