On Thu, 2021-12-02 at 13:09 -0800, Kevin Fenzi wrote: > On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote: > ...snip... > > > > 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; > > This is some kind of seperate signing that happens at build time? > > Or it's added to the rpm metadata and covered by the normal package > signing if/when the package is signed? As part of the signing flow (e.g. via rpmsign), the Merkle tree is generated and a signature is computed from it, which is then added to 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. > > Is this signature key the fedora rpm package signing key? > Or some seperate fsverity key? fs-verity needs a RSA key/cert pair for file signing at package signature time. At package install time, the cert needs to be loaded in the appropriate kernel keyring. We've always used a dedicated keypair during testing -- I'm not actually sure if the package signing key could be reused for this, as it's a GPG key, but this is something we should follow up on. > > fs-verity works by using a Merkle tree to generate a checksum for > > every data block in the system, and reads will fail if a single > > data > > every data block? or every packaged in rpms data block? fs-verity only operates on files where it has been enabled via its ioctl (which, if you install the RPM plugin, is taken care of by RPM on your behalf). For those, fs-verity will checksum every data block whenever it's accessed and validate it still matches. > > block read fails it’s checksum. The signature of the the file is > > validated against a public key loaded into the kernel keyring. > > Because > > fsverity operates on block reads, its runtime cost is small (as it > > only needs to verify the block that is being accessed), and it can > > protect from alterations at any point in time. > > Is this via dm_verity kernel module? Or thats a completely seperate > thing? It's somewhat inspired by dm-verity, but it's a separate implementation, the only shared logic is the hash computation code in the kernel. > > == Scope == > > > > * Proposal owners > > ** btrfs kernel enablement work > > ([ > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=146054090b0859b28fc39015c7704ccc3c3a347f > > landed in 5.15]); see this > > [ > > https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in-btrfs/ > > blog post] for more details > > What does this mean for all the other filesystems? They would just be > slower since btrfs is computing the trees as part of it's normal > checksumming? fs-verity requires support in the underlying filesystem. If you're using a filesystem that doesn't support it and attempt to enable fs- verity on a file, the ioctl will fail. Note that this is only a concern at runtime, not at build time. > > ** koji integration: koji will need to add the fs-verity metadata > > to > > packages when signing them > > Well, koji doesn't sign packages. robosignatory listens for messages > on > the message bus for koji tagging and based on it's config, it asks > sigul > to sign rpms and import the signatures into koji. > > There's support in robosignatory to ask to sign files (used for the > short lived IMA stuff), but I suspect it would need a new ability for > this. > > Finally who is going to write this? Change owners? > Or do you expect robosignatory maintainers to do so? Thanks for clarifying! Yes, I think robosignatory is likely what we want here. We (the Change owners) expect to do the work, though we'll likely need some advice/help around code review, testing and deployment. > > * fs-verity requires filesystem support; currently support for ext4 > > and f2fs is already available; support for btrfs landed in 5.15 > > No xfs support? Correct, XFS doesn't support fs-verity at the moment (though it could be implemented if one wanted to). Cheers Davide _______________________________________________ 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
