On Sat, 2021-12-04 at 23:46 +0100, Kevin Kofler via devel wrote:
Davide Cavalca via devel wrote:
> To clarify: RPM does support files validation, but fs-verity is
> more
> than just that. With RPM, the validation only happens on install
> time,
> and when one runs rpm -V manually. With fs-verity, the validation
> happens on-demand whenever a block of a file that originated from
> an
> RPM is accessed. This means, for example, that if an attacker
> replaces
> /bin/ls on disk with a compromised one, the next time it's read
> from
> disk (e.g. because you ran it) you will see a validation failure
> and
> the syscall will be blocked, preventing the compromised code from
> being
> executed.
This means that there is a performance cost in addition to the disk
space
cost (because something has to compute those checksums each time the
file is
acessed).
There's only a performance cost if fs-verity is actually enabled (which
is not in scope for this proposal). The checksums are computed on-
demand on a per-block basis, so you only end up checksumming the pages
you're actually accessing.
It also means that it is harder for users to exercise their right
to modify the Free Software (because replacing or patching RPM-
installed
binaries will lead to them failing to execute).
There's nothing stopping the user from loading their own key in the
kernel keyring and then installing their own locally-build RPM that has
been verity-signed with their own key. And again, this only becomes a
concern if one is actually enabling fs-verity in the first place.
Since the change also adds to the metadata in the RPM, that means
that it
also increases the size of the RPMs. With keepcache=1, this also
translates
to increased disk space use. But even if the user does not keep
cached RPMs,
the download sizes will increase, which can cost time and for some
users
even money.
That's correct, there will be (modest) increase in the size of the
RPMs. We're going to collect some more data to quantify this more
concretely.
Cheers
Davide