VERITYSETUP(8) | Maintenance Commands | VERITYSETUP(8) |
veritysetup - manage dm-verity (block level verification) volumes
veritysetup <options> <action> <action args>
Veritysetup is used to configure dm-verity managed device-mapper mappings.
Device-mapper verity target provides read-only transparent integrity checking of block devices using kernel crypto API.
The dm-verity devices are always read-only.
Veritysetup supports these operations:
format <data_device> <hash_device>
Note you need to provide root hash string for device verification or activation. Root hash must be trusted.
The data or hash device argument can be block device or file image. If hash device path doesn't exist, it will be created as file.
<options> can be [--hash, --no-superblock, --format, --data-block-size, --hash-block-size, --data-blocks, --hash-offset, --salt, --uuid]
open <data_device> <name> <hash_device>
<root_hash>
create <name> <data_device> <hash_device>
<root_hash> (OBSOLETE syntax)
The <root_hash> is a hexadecimal string.
<options> can be [--hash-offset, --no-superblock, --ignore-corruption or --restart-on-corruption, --panic-on-corruption, --ignore-zero-blocks, --check-at-most-once, --root-hash-signature]
If option --no-superblock is used, you have to use as the same options as in initial format operation.
verify <data_device> <hash_device> <root_hash>
This command performs userspace verification, no kernel device is created.
The <root_hash> is a hexadecimal string.
<options> can be [--hash-offset, --no-superblock]
If option --no-superblock is used, you have to use as the same options as in initial format operation.
close <name>
For backward compatibility there is remove command alias for close command.
status <name>
dump <hash_device>
<options> can be [--no-superblock]
The UUID must be provided in standard UUID format, e.g. 12345678-1234-1234-1234-123456789abc.
Without these options kernel fails the IO operation with I/O error. With --ignore-corruption option the corruption is only logged. With --restart-on-corruption or --panic-on-corruption the kernel is restarted (panicked) immediately. (You have to provide way how to avoid restart loops.)
WARNING: Use these options only for very specific cases. These options are available since Linux kernel version 4.1.
WARNING: Use this option only in very specific cases. This option is available since Linux kernel version 4.5.
WARNING: It provides a reduced level of security because only offline tampering of the data device's content will be detected, not online tampering. This option is available since Linux kernel version 4.17.
The fec device argument can be block device or file image. For format, if fec device path doesn't exist, it will be created as file.
Block sizes for data and hash devices must match. Also, if the verity data_device is encrypted the fec_device should be too.
FEC calculation covers data, hash area, and optional foreign metadata stored on the same device with the hash tree (additional space after hash area). Size of this optional additional area protected by FEC is calculated from image sizes, so you must be sure that you use the same images for activation.
If the hash device is in a separate image, metadata covers the whole rest of the image after the hash area.
If hash and FEC device is in the image, metadata ends on the FEC area offset.
Veritysetup returns 0 on success and a non-zero value on error.
Error codes are:
1 wrong parameters
2 no permission
3 out of memory
4 wrong device specified
5 device already exists or device is busy.
veritysetup --data-blocks=256 format <data_device> <hash_device>
Calculates and stores verification data on hash_device for the first 256 blocks (of block-size). If hash_device does not exist, it is created (as file image).
veritysetup format <data_device> <hash_device>
Calculates and stores verification data on hash_device for the whole data_device.
veritysetup --data-blocks=256 --hash-offset=1052672 format <device> <device>
Verification data (hashes) is stored on the same device as data (starting at hash-offset). Hash-offset must be greater than number of blocks in data-area.
veritysetup --data-blocks=256 --hash-offset=1052672 create test-device <device> <device> <root_hash>
Activates the verity device named test-device. Options --data-blocks and --hash-offset are the same as in the format command. The <root_hash> was calculated in format command.
veritysetup --data-blocks=256 --hash-offset=1052672 verify <data_device> <hash_device> <root_hash>
Verifies device without activation (in userspace).
veritysetup --fec-device=<fec_device> --fec-roots=10 format <data_device> <hash_device>
Calculates and stores verification and encoding data for data_device.
Report bugs, including ones in the documentation, on the cryptsetup mailing list at <dm-crypt@saout.de> or in the 'Issues' section on LUKS website. Please attach the output of the failed command with the --debug option added.
The first implementation of veritysetup was written by Chrome OS authors.
This version is based on verification code written by Mikulas Patocka <mpatocka@redhat.com> and rewritten for libcryptsetup by Milan Broz <gmazyland@gmail.com>.
Copyright © 2012-2021 Red Hat, Inc.
Copyright © 2012-2021 Milan Broz
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The project website at https://gitlab.com/cryptsetup/cryptsetup
The verity on-disk format specification available at https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity
January 2021 | veritysetup |