diff options
| -rw-r--r-- | Documentation/device-mapper/verity.txt | 131 |
1 files changed, 46 insertions, 85 deletions
diff --git a/Documentation/device-mapper/verity.txt b/Documentation/device-mapper/verity.txt index 32e48797a14f..9884681535ee 100644 --- a/Documentation/device-mapper/verity.txt +++ b/Documentation/device-mapper/verity.txt | |||
| @@ -7,39 +7,39 @@ This target is read-only. | |||
| 7 | 7 | ||
| 8 | Construction Parameters | 8 | Construction Parameters |
| 9 | ======================= | 9 | ======================= |
| 10 | <version> <dev> <hash_dev> <hash_start> | 10 | <version> <dev> <hash_dev> |
| 11 | <data_block_size> <hash_block_size> | 11 | <data_block_size> <hash_block_size> |
| 12 | <num_data_blocks> <hash_start_block> | 12 | <num_data_blocks> <hash_start_block> |
| 13 | <algorithm> <digest> <salt> | 13 | <algorithm> <digest> <salt> |
| 14 | 14 | ||
| 15 | <version> | 15 | <version> |
| 16 | This is the version number of the on-disk format. | 16 | This is the type of the on-disk hash format. |
| 17 | 17 | ||
| 18 | 0 is the original format used in the Chromium OS. | 18 | 0 is the original format used in the Chromium OS. |
| 19 | The salt is appended when hashing, digests are stored continuously and | 19 | The salt is appended when hashing, digests are stored continuously and |
| 20 | the rest of the block is padded with zeros. | 20 | the rest of the block is padded with zeros. |
| 21 | 21 | ||
| 22 | 1 is the current format that should be used for new devices. | 22 | 1 is the current format that should be used for new devices. |
| 23 | The salt is prepended when hashing and each digest is | 23 | The salt is prepended when hashing and each digest is |
| 24 | padded with zeros to the power of two. | 24 | padded with zeros to the power of two. |
| 25 | 25 | ||
| 26 | <dev> | 26 | <dev> |
| 27 | This is the device containing the data the integrity of which needs to be | 27 | This is the device containing data, the integrity of which needs to be |
| 28 | checked. It may be specified as a path, like /dev/sdaX, or a device number, | 28 | checked. It may be specified as a path, like /dev/sdaX, or a device number, |
| 29 | <major>:<minor>. | 29 | <major>:<minor>. |
| 30 | 30 | ||
| 31 | <hash_dev> | 31 | <hash_dev> |
| 32 | This is the device that that supplies the hash tree data. It may be | 32 | This is the device that supplies the hash tree data. It may be |
| 33 | specified similarly to the device path and may be the same device. If the | 33 | specified similarly to the device path and may be the same device. If the |
| 34 | same device is used, the hash_start should be outside of the dm-verity | 34 | same device is used, the hash_start should be outside the configured |
| 35 | configured device size. | 35 | dm-verity device. |
| 36 | 36 | ||
| 37 | <data_block_size> | 37 | <data_block_size> |
| 38 | The block size on a data device. Each block corresponds to one digest on | 38 | The block size on a data device in bytes. |
| 39 | the hash device. | 39 | Each block corresponds to one digest on the hash device. |
| 40 | 40 | ||
| 41 | <hash_block_size> | 41 | <hash_block_size> |
| 42 | The size of a hash block. | 42 | The size of a hash block in bytes. |
| 43 | 43 | ||
| 44 | <num_data_blocks> | 44 | <num_data_blocks> |
| 45 | The number of data blocks on the data device. Additional blocks are | 45 | The number of data blocks on the data device. Additional blocks are |
| @@ -65,7 +65,7 @@ Construction Parameters | |||
| 65 | Theory of operation | 65 | Theory of operation |
| 66 | =================== | 66 | =================== |
| 67 | 67 | ||
| 68 | dm-verity is meant to be setup as part of a verified boot path. This | 68 | dm-verity is meant to be set up as part of a verified boot path. This |
| 69 | may be anything ranging from a boot using tboot or trustedgrub to just | 69 | may be anything ranging from a boot using tboot or trustedgrub to just |
| 70 | booting from a known-good device (like a USB drive or CD). | 70 | booting from a known-good device (like a USB drive or CD). |
| 71 | 71 | ||
| @@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller | |||
| 73 | has been authenticated in some way (cryptographic signatures, etc). | 73 | has been authenticated in some way (cryptographic signatures, etc). |
| 74 | After instantiation, all hashes will be verified on-demand during | 74 | After instantiation, all hashes will be verified on-demand during |
| 75 | disk access. If they cannot be verified up to the root node of the | 75 | disk access. If they cannot be verified up to the root node of the |
| 76 | tree, the root hash, then the I/O will fail. This should identify | 76 | tree, the root hash, then the I/O will fail. This should detect |
| 77 | tampering with any data on the device and the hash data. | 77 | tampering with any data on the device and the hash data. |
| 78 | 78 | ||
| 79 | Cryptographic hashes are used to assert the integrity of the device on a | 79 | Cryptographic hashes are used to assert the integrity of the device on a |
| 80 | per-block basis. This allows for a lightweight hash computation on first read | 80 | per-block basis. This allows for a lightweight hash computation on first read |
| 81 | into the page cache. Block hashes are stored linearly-aligned to the nearest | 81 | into the page cache. Block hashes are stored linearly, aligned to the nearest |
| 82 | block the size of a page. | 82 | block size. |
| 83 | 83 | ||
| 84 | Hash Tree | 84 | Hash Tree |
| 85 | --------- | 85 | --------- |
| 86 | 86 | ||
| 87 | Each node in the tree is a cryptographic hash. If it is a leaf node, the hash | 87 | Each node in the tree is a cryptographic hash. If it is a leaf node, the hash |
| 88 | is of some block data on disk. If it is an intermediary node, then the hash is | 88 | of some data block on disk is calculated. If it is an intermediary node, |
| 89 | of a number of child nodes. | 89 | the hash of a number of child nodes is calculated. |
| 90 | 90 | ||
| 91 | Each entry in the tree is a collection of neighboring nodes that fit in one | 91 | Each entry in the tree is a collection of neighboring nodes that fit in one |
| 92 | block. The number is determined based on block_size and the size of the | 92 | block. The number is determined based on block_size and the size of the |
| @@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096 | |||
| 110 | On-disk format | 110 | On-disk format |
| 111 | ============== | 111 | ============== |
| 112 | 112 | ||
| 113 | Below is the recommended on-disk format. The verity kernel code does not | 113 | The verity kernel code does not read the verity metadata on-disk header. |
| 114 | read the on-disk header. It only reads the hash blocks which directly | 114 | It only reads the hash blocks which directly follow the header. |
| 115 | follow the header. It is expected that a user-space tool will verify the | 115 | It is expected that a user-space tool will verify the integrity of the |
| 116 | integrity of the verity_header and then call dmsetup with the correct | 116 | verity header. |
| 117 | parameters. Alternatively, the header can be omitted and the dmsetup | ||
| 118 | parameters can be passed via the kernel command-line in a rooted chain | ||
| 119 | of trust where the command-line is verified. | ||
| 120 | 117 | ||
| 121 | The on-disk format is especially useful in cases where the hash blocks | 118 | Alternatively, the header can be omitted and the dmsetup parameters can |
| 122 | are on a separate partition. The magic number allows easy identification | 119 | be passed via the kernel command-line in a rooted chain of trust where |
| 123 | of the partition contents. Alternatively, the hash blocks can be stored | 120 | the command-line is verified. |
| 124 | in the same partition as the data to be verified. In such a configuration | ||
| 125 | the filesystem on the partition would be sized a little smaller than | ||
| 126 | the full-partition, leaving room for the hash blocks. | ||
| 127 | |||
| 128 | struct superblock { | ||
| 129 | uint8_t signature[8] | ||
| 130 | "verity\0\0"; | ||
| 131 | |||
| 132 | uint8_t version; | ||
| 133 | 1 - current format | ||
| 134 | |||
| 135 | uint8_t data_block_bits; | ||
| 136 | log2(data block size) | ||
| 137 | |||
| 138 | uint8_t hash_block_bits; | ||
| 139 | log2(hash block size) | ||
| 140 | |||
| 141 | uint8_t pad1[1]; | ||
| 142 | zero padding | ||
| 143 | |||
| 144 | uint16_t salt_size; | ||
| 145 | big-endian salt size | ||
| 146 | |||
| 147 | uint8_t pad2[2]; | ||
| 148 | zero padding | ||
| 149 | |||
| 150 | uint32_t data_blocks_hi; | ||
| 151 | big-endian high 32 bits of the 64-bit number of data blocks | ||
| 152 | |||
| 153 | uint32_t data_blocks_lo; | ||
| 154 | big-endian low 32 bits of the 64-bit number of data blocks | ||
| 155 | |||
| 156 | uint8_t algorithm[16]; | ||
| 157 | cryptographic algorithm | ||
| 158 | |||
| 159 | uint8_t salt[384]; | ||
| 160 | salt (the salt size is specified above) | ||
| 161 | |||
| 162 | uint8_t pad3[88]; | ||
| 163 | zero padding to 512-byte boundary | ||
| 164 | } | ||
| 165 | 121 | ||
| 166 | Directly following the header (and with sector number padded to the next hash | 122 | Directly following the header (and with sector number padded to the next hash |
| 167 | block boundary) are the hash blocks which are stored a depth at a time | 123 | block boundary) are the hash blocks which are stored a depth at a time |
| 168 | (starting from the root), sorted in order of increasing index. | 124 | (starting from the root), sorted in order of increasing index. |
| 169 | 125 | ||
| 126 | The full specification of kernel parameters and on-disk metadata format | ||
| 127 | is available at the cryptsetup project's wiki page | ||
| 128 | http://code.google.com/p/cryptsetup/wiki/DMVerity | ||
| 129 | |||
| 170 | Status | 130 | Status |
| 171 | ====== | 131 | ====== |
| 172 | V (for Valid) is returned if every check performed so far was valid. | 132 | V (for Valid) is returned if every check performed so far was valid. |
| @@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned. | |||
| 174 | 134 | ||
| 175 | Example | 135 | Example |
| 176 | ======= | 136 | ======= |
| 177 | 137 | Set up a device: | |
| 178 | Setup a device: | 138 | # dmsetup create vroot --readonly --table \ |
| 179 | dmsetup create vroot --table \ | 139 | "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\ |
| 180 | "0 2097152 "\ | ||
| 181 | "verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\ | ||
| 182 | "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\ | 140 | "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\ |
| 183 | "1234000000000000000000000000000000000000000000000000000000000000" | 141 | "1234000000000000000000000000000000000000000000000000000000000000" |
| 184 | 142 | ||
| 185 | A command line tool veritysetup is available to compute or verify | 143 | A command line tool veritysetup is available to compute or verify |
| 186 | the hash tree or activate the kernel driver. This is available from | 144 | the hash tree or activate the kernel device. This is available from |
| 187 | the LVM2 upstream repository and may be supplied as a package called | 145 | the cryptsetup upstream repository http://code.google.com/p/cryptsetup/ |
| 188 | device-mapper-verity-tools: | 146 | (as a libcryptsetup extension). |
| 189 | git://sources.redhat.com/git/lvm2 | 147 | |
| 190 | http://sourceware.org/git/?p=lvm2.git | 148 | Create hash on the device: |
| 191 | http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2 | 149 | # veritysetup format /dev/sda1 /dev/sda2 |
| 192 | 150 | ... | |
| 193 | veritysetup -a vroot /dev/sda1 /dev/sda2 \ | 151 | Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 |
| 194 | 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 | 152 | |
| 153 | Activate the device: | ||
| 154 | # veritysetup create vroot /dev/sda1 /dev/sda2 \ | ||
| 155 | 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 | ||
