Lines Matching +full:data +full:- +full:size

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
37     This is the device that supplies the hash tree data.  It may be
40     dm-verity device.
43     The block size on a data device in bytes.
47     The size of a hash block in bytes.
50     The number of data blocks on the data device.  Additional blocks are
51     inaccessible.  You can place hashes to the same partition as data, in this
55     This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
97     verification fails. Use encoding data from the specified device. This
98     may be the same device where data and hash blocks reside, in which case
99     fec_start must be outside data and hash areas.
101     If the encoding data covers additional metadata, it must be accessible
104     Note: block sizes for data and hash devices must match. Also, if the
109     the encoding data. For example, in RS(M, N) encoding, the number of roots
110     is M-N.
113     The number of encoding data blocks on the FEC device. The block size for
118     FEC device to the beginning of the encoding data.
121     Verify data blocks only the first time they are read from the data device,
122     rather than every time.  This reduces the overhead of dm-verity so that it
125     data device's content will be detected, not online tampering.
128     since verification of hash blocks is less performance critical than data
129     blocks, and a hash block will not be verified any more after all the data
145     If verity hashes are in cache and the IO size does not exceed the limit,
146     verify data blocks in bottom half instead of workqueue. This option can
147     reduce IO latency. The size limits can be configured via
158 dm-verity is meant to be set up as part of a verified boot path.  This
160 booting from a known-good device (like a USB drive or CD).
162 When a dm-verity device is configured, it is expected that the caller
164 After instantiation, all hashes will be verified on-demand during
167 tampering with any data on the device and the hash data.
170 per-block basis. This allows for a lightweight hash computation on first read
172 block size.
175 corrupted data will be verified using the cryptographic hash of the
176 corresponding data. This is why combining error correction with
180 ---------
183 of some data block on disk is calculated. If it is an intermediary node,
187 block.  The number is determined based on block_size and the size of the
188 selected cryptographic digest algorithm.  The hashes are linearly-ordered in
207 On-disk format
210 The verity kernel code does not read the verity metadata on-disk header.
212 It is expected that a user-space tool will verify the integrity of the
216 be passed via the kernel command-line in a rooted chain of trust where
217 the command-line is verified.
223 The full specification of kernel parameters and on-disk metadata format
237   # dmsetup create vroot --readonly --table \