Lines Matching +full:wp +full:- +full:content
1 .. SPDX-License-Identifier: GPL-2.0
24 binary to perform a malicious action when executed [DMC-CBC-ATTACK]. Since
28 Other full disk encryption systems like dm-crypt cover all filesystem metadata,
31 time. For dm-crypt and other filesystems that build upon the Linux block IO
32 layer, the dm-integrity or dm-verity subsystems [DM-INTEGRITY, DM-VERITY]
34 These can also be combined with dm-crypt [CRYPTSETUP2].
44 ----------------
50 addition, it deals with flash-specific wear-leveling and transparent I/O error
60 +------------+ +*******+ +-----------+ +-----+
61 | | * UBIFS * | UBI-BLOCK | | ... |
62 | JFFS/JFFS2 | +*******+ +-----------+ +-----+
63 | | +-----------------------------+ +-----------+ +-----+
64 | | | UBI | | MTD-BLOCK | | ... |
65 +------------+ +-----------------------------+ +-----------+ +-----+
66 +------------------------------------------------------------------+
68 +------------------------------------------------------------------+
69 +-----------------------------+ +--------------------------+ +-----+
71 +-----------------------------+ +--------------------------+ +-----+
80 - *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data
81 - *Journal*: an additional data structure to collect FS changes before updating
82 the on-flash index and reduce flash wear.
83 - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
84 state to avoid frequent flash reads. It is basically the in-memory
86 - *LEB property tree (LPT)*: an on-flash B+ tree for free space accounting per
89 In the remainder of this section we will cover the on-flash UBIFS data
92 [UBIFS-WP].
98 Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types
103 ``fs/ubifs/ubifs-media.h`` in kernel source). Exceptions are entries of the LPT
105 unusable content at the end of LEBs.
107 To avoid re-writing the whole B+ tree on every single change, it is implemented
108 as *wandering tree*, where only the changed nodes are re-written and previous
117 the most recent on-flash index.
119 The TNC is the in-memory representation of the on-flash index. It contains some
121 a dirty-flag which marks nodes that have to be persisted the next time the
122 index is written onto the flash. The TNC acts as a write-back cache and all
123 modifications of the on-flash index are done through the TNC. Like other caches,
126 on-flash filesystem structures like the index. On every commit, the TNC nodes
137 onto the TNC (which will be created on-demand from the on-flash index).
153 node will be ignored as they are already part of the on-flash index.
160 UBIFS will attempt to recover them by re-reading the LEB. This is however only
167 | ---- LOG AREA ---- | ---------- MAIN AREA ------------ |
169 -----+------+-----+--------+---- ------+-----+-----+---------------
173 ----+------+-----+--------+--- -------+-----+-----+----------------
176 +------------------------+ |
178 +-------------------------------+
189 The LEB property tree is used to store per-LEB information. This includes the
190 LEB type and amount of free and *dirty* (old, obsolete content) space [1]_ on
193 useful for free space calculations. See [UBIFS-WP] for more details.
202 written to without erasing it and previously written content that is obsolete
214 ------------
218 authenticity of on-flash file contents and filesystem metadata. This covers
232 wear-leveling operations of UBI which copies contents from one physical
242 --------------
247 - The index which includes file contents, file metadata like extended
249 - The journal which also contains file contents and metadata by recording changes
251 - The LPT which stores UBI LEB metadata which UBIFS uses for free space accounting
281 +---------------+
284 +---------------+
287 +-------------------+
292 +-------------------+
295 +-------+ +------+
298 +-------------------+ +-------------------+
303 +-------------------+ +-------------------+
306 +-----------+ +----------+ +-----------+
308 +-----------+ +----------+ +-----------+
315 The most important part for robustness and power-cut safety is to atomically
318 UBIFS can safely recover if a power-cut occurs while persisting. Adding
341 ,. CS , hash1.----. hash2.----.
344 ,.REF#0,-> bud -> bud -> bud.-> auth -> bud -> bud.-> auth ...
348 . | hash3,----.
351 , REF#1 -> bud -> bud,-> auth ...
354 REF#2 -> ...
382 LTP hash stored there with the hash computed from the read on-flash LPT.
386 --------------
394 UBIFS authentication is intended to operate side-by-side with UBIFS encryption
398 UBIFS authentication on the other hand has an all-or-nothing approach in the
408 change [FSCRYPT-POLICY2].
419 [FSCRYPT-POLICY2].
438 [CRYPTSETUP2] https://www.saout.de/pipermail/dm-crypt/2017-November/005745.html
440 [DMC-CBC-ATTACK] https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-agains…
442 [DM-INTEGRITY] https://www.kernel.org/doc/Documentation/device-mapper/dm-integrity.rst
444 [DM-VERITY] https://www.kernel.org/doc/Documentation/device-mapper/verity.rst
446 [FSCRYPT-POLICY2] https://www.spinics.net/lists/linux-ext4/msg58710.html
448 [UBIFS-WP] http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf