Lines Matching +full:data +full:- +full:mirror
13 is a lost smartphone where the attacker is unable to read personal data stored
20 binary to perform a malicious action when executed [DMC-CBC-ATTACK]. Since
24 Other full disk encryption systems like dm-crypt cover all filesystem metadata,
27 time. For dm-crypt and other filesystems that build upon the Linux block IO
28 layer, the dm-integrity or dm-verity subsystems [DM-INTEGRITY, DM-VERITY]
29 can be used to get full data authentication at the block layer.
30 These can also be combined with dm-crypt [CRYPTSETUP2].
40 ----------------
46 addition, it deals with flash-specific wear-leveling and transparent I/O error
56 +------------+ +*******+ +-----------+ +-----+
57 | | * UBIFS * | UBI-BLOCK | | ... |
58 | JFFS/JFFS2 | +*******+ +-----------+ +-----+
59 | | +-----------------------------+ +-----------+ +-----+
60 | | | UBI | | MTD-BLOCK | | ... |
61 +------------+ +-----------------------------+ +-----------+ +-----+
62 +------------------------------------------------------------------+
64 +------------------------------------------------------------------+
65 +-----------------------------+ +--------------------------+ +-----+
67 +-----------------------------+ +--------------------------+ +-----+
73 Internally, UBIFS maintains multiple data structures which are persisted on
76 - *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data
77 - *Journal*: an additional data structure to collect FS changes before updating
78 the on-flash index and reduce flash wear.
79 - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
80 state to avoid frequent flash reads. It is basically the in-memory
82 - *LEB property tree (LPT)*: an on-flash B+ tree for free space accounting per
85 In the remainder of this section we will cover the on-flash UBIFS data
88 [UBIFS-WP].
94 Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types
95 of nodes. Eg. data nodes (`struct ubifs_data_node`) which store chunks of file
99 `fs/ubifs/ubifs-media.h`in kernel source). Exceptions are entries of the LPT
103 To avoid re-writing the whole B+ tree on every single change, it is implemented
104 as *wandering tree*, where only the changed nodes are re-written and previous
113 the most recent on-flash index.
115 The TNC is the in-memory representation of the on-flash index. It contains some
117 a dirty-flag which marks nodes that have to be persisted the next time the
118 index is written onto the flash. The TNC acts as a write-back cache and all
119 modifications of the on-flash index are done through the TNC. Like other caches,
120 the TNC does not have to mirror the full index into memory, but reads parts of
122 on-flash filesystem structures like the index. On every commit, the TNC nodes
131 any changes (in form of inode nodes, data nodes etc.) between commits
133 onto the TNC (which will be created on-demand from the on-flash index).
141 other nodes (inode nodes, data nodes etc.) on the flash that are part of this
143 changes including their data.
149 node will be ignored as they are already part of the on-flash index.
156 UBIFS will attempt to recover them by re-reading the LEB. This is however only
163 | ---- LOG AREA ---- | ---------- MAIN AREA ------------ |
165 -----+------+-----+--------+---- ------+-----+-----+---------------
169 ----+------+-----+--------+--- -------+-----+-----+----------------
172 +------------------------+ |
174 +-------------------------------+
185 The LEB property tree is used to store per-LEB information. This includes the
187 the LEB. The type is important, because UBIFS never mixes index nodes with data
189 useful for free space calculations. See [UBIFS-WP] for more details.
210 ------------
212 UBIFS authentication enables detection of offline data modification. While it
214 authenticity of on-flash file contents and filesystem metadata. This covers
228 wear-leveling operations of UBI which copies contents from one physical
238 --------------
240 To be able to fully trust data read from flash, all UBIFS data structures
243 - The index which includes file contents, file metadata like extended
245 - The journal which also contains file contents and metadata by recording changes
247 - The LPT which stores UBI LEB metadata which UBIFS uses for free space accounting
258 data, the hashes of their parent index nodes thus cover all the file contents
277 +---------------+
280 +---------------+
283 +-------------------+
288 +-------------------+
291 +-------+ +------+
294 +-------------------+ +-------------------+
299 +-------------------+ +-------------------+
302 +-----------+ +----------+ +-----------+
303 | Data Node | | INO Node | | DENT Node |
304 +-----------+ +----------+ +-----------+
311 The most important part for robustness and power-cut safety is to atomically
314 UBIFS can safely recover if a power-cut occurs while persisting. Adding
324 journal so that in case of a powercut not too much data can't be authenticated.
337 ,. CS , hash1.----. hash2.----.
340 ,.REF#0,-> bud -> bud -> bud.-> auth -> bud -> bud.-> auth ...
344 . | hash3,----.
347 , REF#1 -> bud -> bud,-> auth ...
350 REF#2 -> ...
378 LTP hash stored there with the hash computed from the read on-flash LPT.
382 --------------
390 UBIFS authentication is intended to operate side-by-side with UBIFS encryption
394 UBIFS authentication on the other hand has an all-or-nothing approach in the
404 change [FSCRYPT-POLICY2].
415 [FSCRYPT-POLICY2].
434 [CRYPTSETUP2] http://www.saout.de/pipermail/dm-crypt/2017-November/005745.html
436 [DMC-CBC-ATTACK] http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against…
438 [DM-INTEGRITY] https://www.kernel.org/doc/Documentation/device-mapper/dm-integrity.rst
440 [DM-VERITY] https://www.kernel.org/doc/Documentation/device-mapper/verity.rst
442 [FSCRYPT-POLICY2] https://www.spinics.net/lists/linux-ext4/msg58710.html
444 [UBIFS-WP] http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf