kernel/linux.git/fs/verity, branch v6.6.132

fsverity: use register_sysctl_init() to avoid kmemleak warning

2024-06-16T11:47:33+00:00

commit ee5814dddefbaa181cb247a75676dd5103775db1 upstream. Since the fsverity sysctl registration runs as a builtin initcall, there is no corresponding sysctl deregistration and the resulting struct ctl_table_header is not used. This can cause a kmemleak warning just after the system boots up. (A pointer to the ctl_table_header is stored in the fsverity_sysctl_header static variable, which kmemleak should detect; however, the compiler can optimize out that variable.) Avoid the kmemleak warning by using register_sysctl_init() which is intended for use by builtin initcalls and uses kmemleak_not_leak(). Reported-by: Yi Zhang Closes: https://lore.kernel.org/r/CAHj4cs8DTSvR698UE040rs_pX1k-WVe7aR6N2OoXXuhXJPDC-w@mail.gmail.com Cc: stable@vger.kernel.org Reviewed-by: Joel Granados Link: https://lore.kernel.org/r/20240501025331.594183-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

fsverity: skip PKCS#7 parser when keyring is empty

2023-08-20T17:33:43+00:00

If an fsverity builtin signature is given for a file but the ".fs-verity" keyring is empty, there's no real reason to run the PKCS#7 parser. Skip this to avoid the PKCS#7 attack surface when builtin signature support is configured into the kernel but is not being used. This is a hardening improvement, not a fix per se, but I've added Fixes and Cc stable to get it out to more users. Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") Cc: stable@vger.kernel.org Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20230820173237.2579-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: move sysctl registration out of signature.c

2023-07-12T05:57:03+00:00

Currently the registration of the fsverity sysctls happens in signature.c, which couples it to CONFIG_FS_VERITY_BUILTIN_SIGNATURES. This makes it hard to add new sysctls unrelated to builtin signatures. Also, some users have started checking whether the directory /proc/sys/fs/verity exists as a way to tell whether fsverity is supported. This isn't the intended method; instead, the existence of /sys/fs/$fstype/features/verity should be checked, or users should just try to use the fsverity ioctls. Regardless, it should be made to work as expected without a dependency on CONFIG_FS_VERITY_BUILTIN_SIGNATURES. Therefore, move the sysctl registration into init.c. With CONFIG_FS_VERITY_BUILTIN_SIGNATURES, nothing changes. Without it, but with CONFIG_FS_VERITY, an empty list of sysctls is now registered. Link: https://lore.kernel.org/r/20230705212743.42180-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: simplify handling of errors during initcall

2023-07-12T05:49:18+00:00

Since CONFIG_FS_VERITY is a bool, not a tristate, fs/verity/ can only be builtin or absent entirely; it can't be a loadable module. Therefore, the error code that gets returned from the fsverity_init() initcall is never used. If any part of the initcall does fail, which should never happen, the kernel will be left in a bad state. Following the usual convention for builtin code, just panic the kernel if any of part of the initcall fails. Link: https://lore.kernel.org/r/20230705212743.42180-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: explicitly check that there is no algorithm 0

2023-07-12T05:49:18+00:00

Since libfsverity and some other code would break if 0 is ever allocated as an FS_VERITY_HASH_ALG_* value, make fsverity_check_hash_algs() explicitly check that there is no algorithm 0. Link: https://lore.kernel.org/r/20230705211719.37713-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: improve documentation for builtin signature support

2023-06-21T05:47:55+00:00

fsverity builtin signatures (CONFIG_FS_VERITY_BUILTIN_SIGNATURES) aren't the only way to do signatures with fsverity, and they have some major limitations. Yet, more users have tried to use them, e.g. recently by https://github.com/ostreedev/ostree/pull/2640. In most cases this seems to be because users aren't sufficiently familiar with the limitations of this feature and what the alternatives are. Therefore, make some updates to the documentation to try to clarify the properties of this feature and nudge users in the right direction. Note that the Integrity Policy Enforcement (IPE) LSM, which is not yet upstream, is planned to use the builtin signatures. (This differs from IMA, which uses its own signature mechanism.) For that reason, my earlier patch "fsverity: mark builtin signatures as deprecated" (https://lore.kernel.org/r/20221208033548.122704-1-ebiggers@kernel.org), which marked builtin signatures as "deprecated", was controversial. This patch therefore stops short of marking the feature as deprecated. I've also revised the language to focus on better explaining the feature and what its alternatives are. Link: https://lore.kernel.org/r/20230620041937.5809-1-ebiggers@kernel.org Reviewed-by: Colin Walters Reviewed-by: Luca Boccassi Signed-off-by: Eric Biggers

fsverity: rework fsverity_get_digest() again

2023-06-14T17:41:07+00:00

Address several issues with the calling convention and documentation of fsverity_get_digest(): - Make it provide the hash algorithm as either a FS_VERITY_HASH_ALG_* value or HASH_ALGO_* value, at the caller's choice, rather than only a HASH_ALGO_* value as it did before. This allows callers to work with the fsverity native algorithm numbers if they want to. HASH_ALGO_* is what IMA uses, but other users (e.g. overlayfs) should use FS_VERITY_HASH_ALG_* to match fsverity-utils and the fsverity UAPI. - Make it return the digest size so that it doesn't need to be looked up separately. Use the return value for this, since 0 works nicely for the "file doesn't have fsverity enabled" case. This also makes it clear that no other errors are possible. - Rename the 'digest' parameter to 'raw_digest' and clearly document that it is only useful in combination with the algorithm ID. This hopefully clears up a point of confusion. - Export it to modules, since overlayfs will need it for checking the fsverity digests of lowerdata files (https://lore.kernel.org/r/dd294a44e8f401e6b5140029d8355f88748cd8fd.1686565330.git.alexl@redhat.com). Acked-by: Mimi Zohar # for the IMA piece Link: https://lore.kernel.org/r/20230612190047.59755-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: simplify error handling in verify_data_block()

2023-06-04T12:56:11+00:00

Clean up the error handling in verify_data_block() to (a) eliminate the 'err' variable which has caused some confusion because the function actually returns a bool, (b) reduce the compiled code size slightly, and (c) execute one fewer branch in the success case. Link: https://lore.kernel.org/r/20230604022312.48532-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fsverity: don't use bio_first_page_all() in fsverity_verify_bio()

2023-06-04T12:56:11+00:00

bio_first_page_all(bio)->mapping->host is not compatible with large folios, since the first page of the bio is not necessarily the head page of the folio, and therefore it might not have the mapping pointer set. Therefore, move the dereference of ->mapping->host into verify_data_blocks(), which works with a folio. (Like the commit that this Fixes, this hasn't actually been tested with large folios yet, since the filesystems that use fs/verity/ don't support that yet. But based on code review, I think this is needed.) Fixes: 5d0f0e57ed90 ("fsverity: support verifying data from large folios") Link: https://lore.kernel.org/r/20230604022101.48342-1-ebiggers@kernel.org Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Eric Biggers

fsverity: constify fsverity_hash_alg

2023-06-04T12:56:11+00:00

Now that fsverity_hash_alg doesn't have an embedded mempool, it can be 'const' almost everywhere. Add it. Link: https://lore.kernel.org/r/20230604022348.48658-1-ebiggers@kernel.org Signed-off-by: Eric Biggers