wireguard-linux/fs/crypto/Kconfig, branch stable

fscrypt: Always use blk-crypto for contents on block-based filesystems

2026-07-20T17:39:25Z

For encrypting and decrypting file contents on block-based filesystems (i.e., ext4 and f2fs, but not ceph and ubifs), always use blk-crypto instead of fs-layer crypto (direct use of crypto_skcipher). Since the blk-crypto API provides a fallback to CPU-based encryption, it's all that's needed on block-based filesystems. The support for two alternative block-based file contents encryption implementations, fs-layer and blk-crypto, existed mainly for historical reasons, as the fs-layer path came first. Some of it is also still needed for the non-block-based filesystems, but a lot of it isn't. Removing the duplicate fs-layer code paths greatly simplifies the code, most of which is done in later commits. Specific implementation details: - SB_INLINECRYPT now controls whether blk_crypto_config::allow_hw is set to true, instead of whether blk-crypto is used at all. The effect is that the semantics are preserved: the inlinecrypt mount option selects the use of inline encryption hardware instead of the CPU. - Set up a blk_crypto_key iff the file is a regular file on a block-based filesystem. To determine whether the filesystem is block-based, add a bit fscrypt_operations::is_block_based. - Remove fscrypt_select_encryption_impl(). Move the logging logic that was previously there into fscrypt_prepare_inline_crypt_key(). Note that blk_crypto_config_supported() is no longer needed. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: use AES library for v1 key derivation

2026-03-25T19:06:33Z

Convert the implementation of the v1 (original / deprecated) fscrypt per-file key derivation algorithm to use the AES library instead of an "ecb(aes)" crypto_skcipher. This is much simpler. While the AES library doesn't support AES-ECB directly yet, we can still simply call aes_encrypt() in a loop. While that doesn't explicitly parallelize the AES encryptions, it doesn't really matter in this case, where a new key is used each time and only 16 to 64 bytes are encrypted. In fact, a quick benchmark (AMD Ryzen 9 9950X) shows that this commit actually greatly improves performance, from ~7000 cycles per key derived to ~1500. The times don't differ much between 32 bytes and 64 bytes either, so clearly the bottleneck is API stuff and key expansion. Granted, performance of the v1 key derivation is no longer very relevant: most users have moved onto v2 encryption policies. The v2 key derivation uses HKDF-SHA512 (which is ~3500 cycles on the same CPU). Still, it's nice that the simpler solution is much faster as well. Compatibility verified with xfstests generic/548. Link: https://lore.kernel.org/r/20260321075338.99809-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: use HMAC-SHA512 library for HKDF

2025-09-06T04:01:51Z

For the HKDF-SHA512 key derivation needed by fscrypt, just use the HMAC-SHA512 library functions directly. These functions were introduced in v6.17, and they provide simple and efficient direct support for HMAC-SHA512. This ends up being quite a bit simpler and more efficient than using crypto/hkdf.c, as it avoids the generic crypto layer: - The HMAC library can't fail, so callers don't need to handle errors - No inefficient indirect calls - No inefficient and error-prone dynamic allocations - No inefficient and error-prone loading of algorithm by name - Less stack usage Benchmarks on x86_64 show that deriving a per-file key gets about 30% faster, and FS_IOC_ADD_ENCRYPTION_KEY gets nearly twice as fast. The only small downside is the HKDF-Expand logic gets duplicated again. Then again, even considering that, the new fscrypt_hkdf_expand() is only 7 lines longer than the version that called hkdf_expand(). Later we could add HKDF support to lib/crypto/, but for now let's just do this. Link: https://lore.kernel.org/r/20250906035913.1141532-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

Merge tag 'for-6.15/block-20250322' of git://git.kernel.dk/linux

2025-03-27T01:08:55Z

Pull block updates from Jens Axboe: - Fixes for integrity handling - NVMe pull request via Keith: - Secure concatenation for TCP transport (Hannes) - Multipath sysfs visibility (Nilay) - Various cleanups (Qasim, Baruch, Wang, Chen, Mike, Damien, Li) - Correct use of 64-bit BARs for pci-epf target (Niklas) - Socket fix for selinux when used in containers (Peijie) - MD pull request via Yu: - fix recovery can preempt resync (Li Nan) - fix md-bitmap IO limit (Su Yue) - fix raid10 discard with REQ_NOWAIT (Xiao Ni) - fix raid1 memory leak (Zheng Qixing) - fix mddev uaf (Yu Kuai) - fix raid1,raid10 IO flags (Yu Kuai) - some refactor and cleanup (Yu Kuai) - Series cleaning up and fixing bugs in the bad block handling code - Improve support for write failure simulation in null_blk - Various lock ordering fixes - Fixes for locking for debugfs attributes - Various ublk related fixes and improvements - Cleanups for blk-rq-qos wait handling - blk-throttle fixes - Fixes for loop dio and sync handling - Fixes and cleanups for the auto-PI code - Block side support for hardware encryption keys in blk-crypto - Various cleanups and fixes * tag 'for-6.15/block-20250322' of git://git.kernel.dk/linux: (105 commits) nvmet: replace max(a, min(b, c)) by clamp(val, lo, hi) nvme-tcp: fix selinux denied when calling sock_sendmsg nvmet: pci-epf: Always configure BAR0 as 64-bit nvmet: Remove duplicate uuid_copy nvme: zns: Simplify nvme_zone_parse_entry() nvmet: pci-epf: Remove redundant 'flush_workqueue()' calls nvmet-fc: Remove unused functions nvme-pci: remove stale comment nvme-fc: Utilise min3() to simplify queue count calculation nvme-multipath: Add visibility for queue-depth io-policy nvme-multipath: Add visibility for numa io-policy nvme-multipath: Add visibility for round-robin io-policy nvmet: add tls_concat and tls_key debugfs entries nvmet-tcp: support secure channel concatenation nvmet: Add 'sq' argument to alloc_ctrl_args nvme-fabrics: reset admin connection for secure concatenation nvme-tcp: request secure channel concatenation nvme-keyring: add nvme_tls_psk_refresh() nvme: add nvme_auth_derive_tls_psk() nvme: add nvme_auth_generate_digest() ...

crypto,fs: Separate out hkdf_extract() and hkdf_expand()

2025-03-20T23:53:53Z

Separate out the HKDF functions into a separate module to to make them available to other callers. And add a testsuite to the module with test vectors from RFC 5869 (and additional vectors for SHA384 and SHA512) to ensure the integrity of the algorithm. Signed-off-by: Hannes Reinecke Acked-by: Eric Biggers Acked-by: Herbert Xu Signed-off-by: Keith Busch

Revert "fscrypt: relax Kconfig dependencies for crypto API algorithms"

2025-02-17T19:33:32Z

This mostly reverts commit a0fc20333ee4bac1147c4cf75dea098c26671a2f. Keep the relevant parts of the comment added by that commit. The problem with that commit is that it allowed people to create broken configurations that enabled FS_ENCRYPTION but not the mandatory algorithms. An example of this can be found here: https://lore.kernel.org/r/1207325.1737387826@warthog.procyon.org.uk/ The commit did allow people to disable specific generic algorithm implementations that aren't needed. But that at best allowed saving a bit of code. In the real world people are unlikely to intentionally and correctly make such a tweak anyway, as they tend to just be confused by what all the different crypto kconfig options mean. Of course we really need the crypto API to enable the correct implementations automatically, but that's for a later fix. Acked-by: Ard Biesheuvel Cc: David Howells Cc: Herbert Xu Link: https://lore.kernel.org/r/20250217185314.27345-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: document that CephFS supports fscrypt now

2023-12-27T04:55:42Z

The help text for CONFIG_FS_ENCRYPTION and the fscrypt.rst documentation file both list the filesystems that support fscrypt. CephFS added support for fscrypt in v6.6, so add CephFS to the list. Link: https://lore.kernel.org/r/20231227045158.87276-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: relax Kconfig dependencies for crypto API algorithms

2021-04-22T07:31:32Z

Even if FS encryption has strict functional dependencies on various crypto algorithms and chaining modes. those dependencies could potentially be satisified by other implementations than the generic ones, and no link time dependency exists on the 'depends on' claused defined by CONFIG_FS_ENCRYPTION_ALGS. So let's relax these clauses to 'imply', so that the default behavior is still to pull in those generic algorithms, but in a way that permits them to be disabled again in Kconfig. Signed-off-by: Ard Biesheuvel Acked-by: Eric Biggers Signed-off-by: Herbert Xu

fscrypt: switch fscrypt_do_sha256() to use the SHA-256 library

2020-07-21T23:02:13Z

fscrypt_do_sha256() is only used for hashing encrypted filenames to create no-key tokens, which isn't performance-critical. Therefore a C implementation of SHA-256 is sufficient. Also, the logic to create no-key tokens is always potentially needed. This differs from fscrypt's other dependencies on crypto API algorithms, which are conditionally needed depending on what encryption policies userspace is using. Therefore, for fscrypt there isn't much benefit to allowing SHA-256 to be a loadable module. So, make fscrypt_do_sha256() use the SHA-256 library instead of the crypto_shash API. This is much simpler, since it avoids having to implement one-time-init (which is hard to do correctly, and in fact was implemented incorrectly) and handle failures to allocate the crypto_shash object. Fixes: edc440e3d27f ("fscrypt: improve format of no-key names") Cc: Daniel Rosenberg Link: https://lore.kernel.org/r/20200721225920.114347-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: add inline encryption support

2020-07-08T17:29:30Z

Add support for inline encryption to fs/crypto/. With "inline encryption", the block layer handles the decryption/encryption as part of the bio, instead of the filesystem doing the crypto itself via Linux's crypto API. This model is needed in order to take advantage of the inline encryption hardware present on most modern mobile SoCs. To use inline encryption, the filesystem needs to be mounted with '-o inlinecrypt'. Blk-crypto will then be used instead of the traditional filesystem-layer crypto whenever possible to encrypt the contents of any encrypted files in that filesystem. Fscrypt still provides the key and IV to use, and the actual ciphertext on-disk is still the same; therefore it's testable using the existing fscrypt ciphertext verification tests. Note that since blk-crypto has a fallback to Linux's crypto API, and also supports all the encryption modes currently supported by fscrypt, this feature is usable and testable even without actual inline encryption hardware. Per-filesystem changes will be needed to set encryption contexts when submitting bios and to implement the 'inlinecrypt' mount option. This patch just adds the common code. Signed-off-by: Satya Tangirala Reviewed-by: Jaegeuk Kim Reviewed-by: Eric Biggers Reviewed-by: Theodore Ts'o Link: https://lore.kernel.org/r/20200702015607.1215430-3-satyat@google.com Co-developed-by: Eric Biggers Signed-off-by: Eric Biggers