Lines Matching +full:single +full:- +full:master
1 .. SPDX-License-Identifier: GPL-2.0
16 read contents of the filesystem on a single point in time. A classic example
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
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
110 the index is not stored in a single place on the flash, but *wanders* around
113 a special node called *master node* into UBI LEB 1 which always points to the
114 most recent root node of the UBIFS index. For recoverability, the master node
116 LEB 1 and 2 to get the current master node and from there get the location of
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
192 nodes on a single LEB and thus each LEB has a specific purpose. This again is
193 useful for free space calculations. See [UBIFS-WP] for more details.
214 ------------
218 authenticity of on-flash file contents and filesystem metadata. This covers
230 will always write a new version of the index root node and the master node
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
264 from the leaf nodes up to the root node including the master node. This process
269 To ensure the authenticity of the whole index, the UBIFS master node stores a
271 tree. As mentioned above, the master node is always written to the flash whenever
274 Using this approach only UBIFS index nodes and the master node are changed to
281 +---------------+
282 | Master Node |
284 +---------------+
287 +-------------------+
292 +-------------------+
295 +-------+ +------+
298 +-------------------+ +-------------------+
303 +-------------------+ +-------------------+
306 +-----------+ +----------+ +-----------+
308 +-----------+ +----------+ +-----------+
311 Figure 3: Coverage areas of index node hash and master node HMAC
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 -> ...
364 The location of the log area is stored in the master node. Since the master
376 The location of the LPT root node on the flash is stored in the UBIFS master
379 protect the integrity of the full LPT by a simple hash stored in the master
380 node. Since the master node itself is authenticated, the LPTs authenticity can
381 be verified by verifying the authenticity of the master node and comparing the
382 LTP hash stored there with the hash computed from the read on-flash LPT.
386 --------------
388 For simplicity, UBIFS authentication uses a single key to compute the HMACs
389 of superblock, master, commit start and reference nodes. This key has to be
394 UBIFS authentication is intended to operate side-by-side with UBIFS encryption
397 multiple fscrypt master keys and there might be folders without encryption.
398 UBIFS authentication on the other hand has an all-or-nothing approach in the
401 encryption, it does not share the same master key with fscrypt, but manages
408 change [FSCRYPT-POLICY2].
410 Nevertheless, it will be possible for a user to provide a single passphrase
413 authentication in addition to the derived fscrypt master key used for
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