2019-07-22 09:26:21 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
|
|
|
config FS_VERITY
|
|
|
|
bool "FS Verity (read-only file-based authenticity protection)"
|
|
|
|
select CRYPTO
|
2021-11-23 11:37:52 -07:00
|
|
|
select CRYPTO_HASH_INFO
|
2021-04-21 00:55:11 -07:00
|
|
|
# SHA-256 is implied as it's intended to be the default hash algorithm.
|
2019-07-22 09:26:21 -07:00
|
|
|
# To avoid bloat, other wanted algorithms must be selected explicitly.
|
2021-04-21 00:55:11 -07:00
|
|
|
# Note that CRYPTO_SHA256 denotes the generic C implementation, but
|
|
|
|
# some architectures provided optimized implementations of the same
|
|
|
|
# algorithm that may be used instead. In this case, CRYPTO_SHA256 may
|
|
|
|
# be omitted even if SHA-256 is being used.
|
|
|
|
imply CRYPTO_SHA256
|
2019-07-22 09:26:21 -07:00
|
|
|
help
|
|
|
|
This option enables fs-verity. fs-verity is the dm-verity
|
|
|
|
mechanism implemented at the file level. On supported
|
2022-06-09 17:06:16 -07:00
|
|
|
filesystems (currently ext4, f2fs, and btrfs), userspace can
|
|
|
|
use an ioctl to enable verity for a file, which causes the
|
|
|
|
filesystem to build a Merkle tree for the file. The filesystem
|
|
|
|
will then transparently verify any data read from the file
|
|
|
|
against the Merkle tree. The file is also made read-only.
|
2019-07-22 09:26:21 -07:00
|
|
|
|
|
|
|
This serves as an integrity check, but the availability of the
|
|
|
|
Merkle tree root hash also allows efficiently supporting
|
|
|
|
various use cases where normally the whole file would need to
|
|
|
|
be hashed at once, such as: (a) auditing (logging the file's
|
|
|
|
hash), or (b) authenticity verification (comparing the hash
|
|
|
|
against a known good value, e.g. from a digital signature).
|
|
|
|
|
|
|
|
fs-verity is especially useful on large files where not all
|
|
|
|
the contents may actually be needed. Also, fs-verity verifies
|
|
|
|
data each time it is paged back in, which provides better
|
|
|
|
protection against malicious disks vs. an ahead-of-time hash.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2019-07-22 09:26:23 -07:00
|
|
|
config FS_VERITY_BUILTIN_SIGNATURES
|
|
|
|
bool "FS Verity builtin signature support"
|
|
|
|
depends on FS_VERITY
|
|
|
|
select SYSTEM_DATA_VERIFICATION
|
|
|
|
help
|
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/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 <walters@verbum.org>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2023-06-19 21:19:37 -07:00
|
|
|
This option adds support for in-kernel verification of
|
|
|
|
fs-verity builtin signatures.
|
2019-07-22 09:26:23 -07:00
|
|
|
|
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/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 <walters@verbum.org>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2023-06-19 21:19:37 -07:00
|
|
|
Please take great care before using this feature. It is not
|
|
|
|
the only way to do signatures with fs-verity, and the
|
|
|
|
alternatives (such as userspace signature verification, and
|
|
|
|
IMA appraisal) can be much better. For details about the
|
|
|
|
limitations of this feature, see
|
|
|
|
Documentation/filesystems/fsverity.rst.
|
2019-07-22 09:26:23 -07:00
|
|
|
|
|
|
|
If unsure, say N.
|