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: dcavalca@xxxxxx, borisb@xxxxxx, filbranden@xxxxxx, michel@xxxxxx, malmond@xxxxxx == 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
