summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2016-01-12 06:25:00 (GMT)
committerLinus Torvalds <torvalds@linux-foundation.org>2016-01-12 06:25:00 (GMT)
commit03891f9c853d5c4473224478a1e03ea00d70ff8d (patch)
tree63e3d6849f65ecf0f230a748c09ed09970ec981d /Documentation
parent47c62e4be78303ef52ffa8134026919d0890c5a9 (diff)
parent385277bfb57faac44e92497104ba542cdd82d5fe (diff)
downloadlinux-03891f9c853d5c4473224478a1e03ea00d70ff8d.tar.xz
Merge tag 'dm-4.5-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper updates from Mike Snitzer: - The most significant set of changes this cycle is the Forward Error Correction (FEC) support that has been added to the DM verity target. Google uses DM verity on all Android devices and it is believed that this FEC support will enable DM verity to recover from storage failures seen since DM verity was first deployed as part of Android. - A stable fix for a race in the destruction of DM thin pool's workqueue - A stable fix for hung IO if a DM snapshot copy hit an error - A few small cleanups in DM core and DM persistent data. - A couple DM thinp range discard improvements (address atomicity of finding a range and the efficiency of discarding a partially mapped thin device) - Add ability to debug DM bufio leaks by recording stack trace when a buffer is allocated. Upon detected leak the recorded stack is dumped. * tag 'dm-4.5-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm snapshot: fix hung bios when copy error occurs dm thin: bump thin and thin-pool target versions dm thin: fix race condition when destroying thin pool workqueue dm space map metadata: remove unused variable in brb_pop() dm verity: add ignore_zero_blocks feature dm verity: add support for forward error correction dm verity: factor out verity_for_bv_block() dm verity: factor out structures and functions useful to separate object dm verity: move dm-verity.c to dm-verity-target.c dm verity: separate function for parsing opt args dm verity: clean up duplicate hashing code dm btree: factor out need_insert() helper dm bufio: use BUG_ON instead of conditional call to BUG dm bufio: store stacktrace in buffers to help find buffer leaks dm bufio: return NULL to improve code clarity dm block manager: cleanup code that prints stacktrace dm: don't save and restore bi_private dm thin metadata: make dm_thin_find_mapped_range() atomic dm thin metadata: speed up discard of partially mapped volumes
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/device-mapper/verity.txt40
1 files changed, 38 insertions, 2 deletions
diff --git a/Documentation/device-mapper/verity.txt b/Documentation/device-mapper/verity.txt
index e15bc1a..89fd8f9 100644
--- a/Documentation/device-mapper/verity.txt
+++ b/Documentation/device-mapper/verity.txt
@@ -18,11 +18,11 @@ Construction Parameters
0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
- the rest of the block is padded with zeros.
+ the rest of the block is padded with zeroes.
1 is the current format that should be used for new devices.
The salt is prepended when hashing and each digest is
- padded with zeros to the power of two.
+ padded with zeroes to the power of two.
<dev>
This is the device containing data, the integrity of which needs to be
@@ -79,6 +79,37 @@ restart_on_corruption
not compatible with ignore_corruption and requires user space support to
avoid restart loops.
+ignore_zero_blocks
+ Do not verify blocks that are expected to contain zeroes and always return
+ zeroes instead. This may be useful if the partition contains unused blocks
+ that are not guaranteed to contain zeroes.
+
+use_fec_from_device <fec_dev>
+ Use forward error correction (FEC) to recover from corruption if hash
+ verification fails. Use encoding data from the specified device. This
+ may be the same device where data and hash blocks reside, in which case
+ fec_start must be outside data and hash areas.
+
+ If the encoding data covers additional metadata, it must be accessible
+ on the hash device after the hash blocks.
+
+ Note: block sizes for data and hash devices must match. Also, if the
+ verity <dev> is encrypted the <fec_dev> should be too.
+
+fec_roots <num>
+ Number of generator roots. This equals to the number of parity bytes in
+ the encoding data. For example, in RS(M, N) encoding, the number of roots
+ is M-N.
+
+fec_blocks <num>
+ The number of encoding data blocks on the FEC device. The block size for
+ the FEC device is <data_block_size>.
+
+fec_start <offset>
+ This is the offset, in <data_block_size> blocks, from the start of the
+ FEC device to the beginning of the encoding data.
+
+
Theory of operation
===================
@@ -98,6 +129,11 @@ per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly, aligned to the nearest
block size.
+If forward error correction (FEC) support is enabled any recovery of
+corrupted data will be verified using the cryptographic hash of the
+corresponding data. This is why combining error correction with
+integrity checking is essential.
+
Hash Tree
---------