| 919dc320 | 02-Aug-2023 |
Eric Biggers <[email protected]> |
fsverity: skip PKCS#7 parser when keyring is empty
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
fsverity: skip PKCS#7 parser when keyring is empty
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: [email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 456ae5fe | 05-Jul-2023 |
Eric Biggers <[email protected]> |
fsverity: move sysctl registration out of signature.c
Currently the registration of the fsverity sysctls happens in signature.c, which couples it to CONFIG_FS_VERITY_BUILTIN_SIGNATURES.
This makes
fsverity: move sysctl registration out of signature.c
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/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| e77000cc | 05-Jul-2023 |
Eric Biggers <[email protected]> |
fsverity: simplify handling of errors during initcall
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,
fsverity: simplify handling of errors during initcall
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/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 672d6ef4 | 20-Jun-2023 |
Eric Biggers <[email protected]> |
fsverity: improve documentation for builtin signature support
fsverity builtin signatures (CONFIG_FS_VERITY_BUILTIN_SIGNATURES) aren't the only way to do signatures with fsverity, and they have some
fsverity: improve documentation for builtin signature support
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/[email protected]), 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/[email protected] Reviewed-by: Colin Walters <[email protected]> Reviewed-by: Luca Boccassi <[email protected]> Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 74836ecb | 12-Jun-2023 |
Eric Biggers <[email protected]> |
fsverity: rework fsverity_get_digest() again
Address several issues with the calling convention and documentation of fsverity_get_digest():
- Make it provide the hash algorithm as either a FS_VERIT
fsverity: rework fsverity_get_digest() again
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 <[email protected]> # for the IMA piece Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 13e2408d | 04-Jun-2023 |
Eric Biggers <[email protected]> |
fsverity: simplify error handling in verify_data_block()
Clean up the error handling in verify_data_block() to (a) eliminate the 'err' variable which has caused some confusion because the function a
fsverity: simplify error handling in verify_data_block()
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/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| d1f0c5ea | 04-Jun-2023 |
Eric Biggers <[email protected]> |
fsverity: don't use bio_first_page_all() in fsverity_verify_bio()
bio_first_page_all(bio)->mapping->host is not compatible with large folios, since the first page of the bio is not necessarily the h
fsverity: don't use bio_first_page_all() in fsverity_verify_bio()
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/[email protected] Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 32ab3c5e | 04-Jun-2023 |
Eric Biggers <[email protected]> |
fsverity: constify fsverity_hash_alg
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-
fsverity: constify fsverity_hash_alg
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/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 04839139 | 06-Apr-2023 |
Eric Biggers <[email protected]> |
fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds
Commit 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read th
fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds
Commit 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read the file's data, instead of direct pagecache accesses.
An unintended consequence of this is that the 'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called on a fd opened with access mode 3, which means "ioctl access only".
Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But ioctl-only fds are a weird Linux extension that is rarely used and that few people even know about. (The documentation for FS_IOC_ENABLE_VERITY even specifically says it requires O_RDONLY.) It's probably not worthwhile to make the ioctl internally open a new fd just to handle this case. Thus, just reject the ioctl on such fds for now.
Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=2281afcbbfa8fdb92f9887479cc0e4180f1c6b28 Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 39049b69 | 28-Mar-2023 |
Eric Biggers <[email protected]> |
fsverity: explicitly check for buffer overflow in build_merkle_tree()
The new Merkle tree construction algorithm is a bit fragile in that it may overflow the 'root_hash' array if the tree actually g
fsverity: explicitly check for buffer overflow in build_merkle_tree()
The new Merkle tree construction algorithm is a bit fragile in that it may overflow the 'root_hash' array if the tree actually generated does not match the calculated tree parameters.
This should never happen unless there is a filesystem bug that allows the file size to change despite deny_write_access(), or a bug in the Merkle tree logic itself. Regardless, it's fairly easy to check for buffer overflow here, so let's do so.
This is a robustness improvement only; this case is not currently known to be reachable. I've added a Fixes tag anyway, since I recommend that this be included in kernels that have the mentioned commit.
Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| 8eb8af4b | 28-Mar-2023 |
Eric Biggers <[email protected]> |
fsverity: use WARN_ON_ONCE instead of WARN_ON
As per Linus's suggestion (https://lore.kernel.org/r/CAHk-=whefxRGyNGzCzG6BVeM=5vnvgb-XhSeFJVxJyAxAF8XRA@mail.gmail.com), use WARN_ON_ONCE instead of WA
fsverity: use WARN_ON_ONCE instead of WARN_ON
As per Linus's suggestion (https://lore.kernel.org/r/CAHk-=whefxRGyNGzCzG6BVeM=5vnvgb-XhSeFJVxJyAxAF8XRA@mail.gmail.com), use WARN_ON_ONCE instead of WARN_ON. This barely adds any extra overhead, and it makes it so that if any of these ever becomes reachable (they shouldn't, but that's the point), the logs can't be flooded.
Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Eric Biggers <[email protected]>
show more ...
|
| a075bacd | 14-Mar-2023 |
Eric Biggers <[email protected]> |
fsverity: don't drop pagecache at end of FS_IOC_ENABLE_VERITY
The full pagecache drop at the end of FS_IOC_ENABLE_VERITY is causing performance problems and is hindering adoption of fsverity. It wa
fsverity: don't drop pagecache at end of FS_IOC_ENABLE_VERITY
The full pagecache drop at the end of FS_IOC_ENABLE_VERITY is causing performance problems and is hindering adoption of fsverity. It was intended to solve a race condition where unverified pages might be left in the pagecache. But actually it doesn't solve it fully.
Since the incomplete solution for this race condition has too much performance impact for it to be worth it, let's remove it for now.
Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl") Cc: [email protected] Reviewed-by: Victor Hsieh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
show more ...
|