componefs is a new file system proposed for Linux
Recently the news broke that Alexander Larson, the creator of Flatpak at Red Hat, has posted a preview of the patches that implement the file system ComposeFS for the Linux kernel.
The proposed file system resembles Squashfs and is also suitable for mounting read-only images. The differences boil down to ComposeFS's ability to efficiently share the contents of multiple mounted disk images and support for readable data authentication.
Application areas where ComposeFS may be in demand are mounting container images and using a Git-like OSTree repository. This allows content files to be shared between images, even if metadata (such as timestamps or file ownership) varies between images.
ComposeFS uses a content-based addressing storage model, that is, the primary identifier is not the file name, but a hash of the file's contents. This model provides deduplication and allows to store only one copy of the same files found on different mounted partitions.
In essence, composefs is a way to build and use read-only images. which are used similarly to how you would use, for example, loopback squash images. In addition to this composefs has two new fundamentals features. First, it allows file data to be shared (both on disk and on page cache) between images, and secondly you have dm-verity like read validation.
For example, container images contain many common files system and with Composefs, each of these files will be shared by all mounted images, without the use of tricks like forwarding with hard links.
At the same time, shared files are not only stored as a single copy on disk, but are also managed by an entry in the page cache, allowing both disk and RAM to be saved.
Composefs also supports fs-verity validation of content files. Using this, the digest of the content files is stored in the image and composefs will validate that the content file it uses has an fs-verity digest enabled for matching. This means that the backing content cannot be changed in any way (by mistake or malice) without being detected when the file is used.
You can also use fs-verity on the image file itself and pass the expected fs-verity digest as a mount option, which will be validated by composefs. In this case, we have full confidence in both the data and the metadata of the mounted file. This resolves a weakness that fs-verity has when used alone, in that it can only verify file data, not metadata.
To save disk space, data and metadata are separated in mounted images. When mounted, specify:
- A binary index that contains all file system metadata, file names, permissions, and other information except the actual contents of the files.
- The base directory where the content of all mounted image files is stored. Files are stored relative to the hash of their content.
- A binary index is created for each FS image and the base directory is the same for all images. To verify the content of individual files and the entire image under shared storage conditions, the fs-verity mechanism can be used, which, when accessing files, verifies that the hashes specified in the binary index correspond to the content. real (that is, if an attacker makes a change to a file in the base directory or data is corrupted as a result of a failure, such reconciliation will reveal a discrepancy).
finally if you are interested in knowing more about it, you can check the details in the following link.