Lines Matching +full:on +full:- +full:flash
1 .. SPDX-License-Identifier: GPL-2.0
16 read contents of the filesystem on a single point in time. A classic example
18 on the device without the filesystem decryption key.
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 ----------------
46 On Linux, the MTD (Memory Technology Devices) subsystem provides a uniform
47 interface to access raw flash devices. One of the more prominent subsystems that
48 work on top of MTD is UBI (Unsorted Block Images). It provides volume management
49 for flash devices and is thus somewhat similar to LVM for block devices. In
50 addition, it deals with flash-specific wear-leveling and transparent I/O error
51 handling. UBI offers logical erase blocks (LEBs) to the layers on top of it
52 and maps them transparently to physical erase blocks (PEBs) on the flash.
54 UBIFS is a filesystem for raw flash which operates on top of UBI. Thus, wear
55 leveling and some flash specifics are left to UBI, while UBIFS focuses on
60 +------------+ +*******+ +-----------+ +-----+
61 | | * UBIFS * | UBI-BLOCK | | ... |
62 | JFFS/JFFS2 | +*******+ +-----------+ +-----+
63 | | +-----------------------------+ +-----------+ +-----+
64 | | | UBI | | MTD-BLOCK | | ... |
65 +------------+ +-----------------------------+ +-----------+ +-----+
66 +------------------------------------------------------------------+
68 +------------------------------------------------------------------+
69 +-----------------------------+ +--------------------------+ +-----+
71 +-----------------------------+ +--------------------------+ +-----+
73 Figure 1: Linux kernel subsystems for dealing with raw flash
77 Internally, UBIFS maintains multiple data structures which are persisted on
78 the flash:
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
91 persisted onto the flash directly. More details on UBIFS can also be found in
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
111 and there are obsolete parts on the flash as long as the LEB containing them is
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,
125 it from flash whenever needed. A *commit* is the UBIFS operation of updating the
126 on-flash filesystem structures like the index. On every commit, the TNC nodes
127 marked as dirty are written to the flash to update the persisted index.
133 To avoid wearing out the flash, the index is only persisted (*committed*) when
136 of the index. During mount, the journal is read from the flash and replayed
137 onto the TNC (which will be created on-demand from the on-flash index).
140 amount of log area LEBs is configured on filesystem creation (using
144 written on every journal update. Each reference node points to the position of
145 other nodes (inode nodes, data nodes etc.) on the flash that are part of this
153 node will be ignored as they are already part of the on-flash index.
158 On replay, UBIFS will record every reference node and inspect the location of
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 +-------------------------------+
181 Figure 2: UBIFS flash layout of log area with commit start nodes
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
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.
196 index. Due to its smaller size it is always written as one chunk on every
201 difference between free space ie. the remaining space left on the LEB to be
210 the authenticity and integrity of metadata and file contents stored on flash.
214 ------------
218 authenticity of on-flash file contents and filesystem metadata. This covers
221 UBIFS authentication will not protect against rollback of full flash contents.
222 Ie. an attacker can still dump the flash and restore it at a later time without
228 erasing parts of the current tree and restoring old versions that are still on
229 the flash and have not yet been erased. This is possible, because every commit
232 wear-leveling operations of UBI which copies contents from one physical
236 execute code on the device after the authentication key was provided.
238 ensure that only trusted code is executed on a device.
242 --------------
244 To be able to fully trust data read from flash, all UBIFS data structures
245 stored on flash are authenticated. That is:
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
271 tree. As mentioned above, the master node is always written to the flash whenever
272 the index is persisted (ie. on index commit).
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 -> ...
370 modified on feature flag or similar changes, but never on file changes.
376 The location of the LPT root node on the flash is stored in the UBIFS master
377 node. Since the LPT is written and read atomically on every commit, there is
382 LTP hash stored there with the hash computed from the read on-flash LPT.
386 --------------
390 available on creation of the filesystem (`mkfs.ubifs`) to authenticate the
391 superblock node. Further, it has to be available on mount of the filesystem
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].
416 To be able to check if the proper key is available on mount, the UBIFS
419 [FSCRYPT-POLICY2].
430 UBIFS can exchange all digital signatures with HMACs on first mount similar
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