On 12/2/21 11:36, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/FsVerityRPM
== Summary ==
Enable the use of fsverity for installed RPM files validation.
== Owners ==
* Name: [[User:Dcavalca|Davide Cavalca]], [[User:Borisb|Boris
Burkov]], [[User:Filbranden|Filipe Brandenburger]],
[[User:Salimma|Michel Alexandre Salim]], [[User:Malmond|Matthew
Almond]]
* Email: dcava...@fb.com, bor...@fb.com, filbran...@fb.com,
mic...@fb.com, malm...@fb.com
== Detailed description ==
fs-verity is a [https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
Linux kernel feature] that does transparent on-demand
integrity/authenticity verification of the contents of read-only
files, using a hidden Merkle tree (hash tree) associated with the
file. The mechanism is similar to dm-verity, but implemented at the
file level rather than at the block device level.
When fsverity is enabled for a file, the kernel reads every block and
generates a hash tree for it, which is stored within the filesystem.
On subsequent reads, the kernel computes the block hash and compares
it with the one stored in the tree, protecting against alterations and
corruption. Because this happens at the filesystem data block read
layer, it encompasses all file operations (<code>open</code>,
<code>mmap</code>,<code>exec</code>, etc.).
In the context of rpm, there are two parts to this:
* at build time, we compute the Merkle tree for the files within a
package, then sign it and ship it as part of the rpm metadata;
* at run time, if the fsverity rpm plugin is enabled, rpm will install
the fsverity signature key and enable fsverity on files that are
installed.
This proposal is primarily concerned with the first part, which will
make it possible for users to leverage fs-verity for RPM if they so
desire. Specifically, installing and enabling the fs-verity rpm plugin
by default is explicitly considered out of scope here.
=== Caveats ===
==== Merkle tree cost ====
The Merkle tree used by fsverity needs to be generated (once at build
time, once when the package is installed) and stored on disk. The
generation process involves reading all blocks and computing the hash,
which has a non-trivial cost; however, it does not appear to
meaningfully slow down package installs during empirical testing. Once
Did you test the impact this has on package build times? Particularly
packages like llvm, clang, webkit2gtk3, etc. that have very large debuginfo
files?
-Tom
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
