fscrypt updates for 6.15

A fix for an issue where CONFIG_FS_ENCRYPTION could be enabled without
 some of its dependencies, and a small documentation update.
 -----BEGIN PGP SIGNATURE-----
 
 iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCZ+CBShQcZWJpZ2dlcnNA
 Z29vZ2xlLmNvbQAKCRDzXCl4vpKOKxj0AQC4OlE/HbIY2w3zO8Az9WEF9+4Dz9od
 EpxTwO/fk9PC+gD/Z7r8J3xn+ykcy9QcZW+Qucd64k+rbmvqj36gXce6hAI=
 =r+lX
 -----END PGP SIGNATURE-----

Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux

Pull fscrypt updates from Eric Biggers:
 "A fix for an issue where CONFIG_FS_ENCRYPTION could be enabled without
  some of its dependencies, and a small documentation update"

* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux:
  fscrypt: mention init_on_free instead of page poisoning
  fscrypt: drop obsolete recommendation to enable optimized ChaCha20
  Revert "fscrypt: relax Kconfig dependencies for crypto API algorithms"
This commit is contained in:
Linus Torvalds 2025-03-25 18:31:38 -07:00
commit a86c6d0b2a
2 changed files with 10 additions and 18 deletions

View file

@ -137,9 +137,8 @@ However, these ioctls have some limitations:
- In general, decrypted contents and filenames in the kernel VFS - In general, decrypted contents and filenames in the kernel VFS
caches are freed but not wiped. Therefore, portions thereof may be caches are freed but not wiped. Therefore, portions thereof may be
recoverable from freed memory, even after the corresponding key(s) recoverable from freed memory, even after the corresponding key(s)
were wiped. To partially solve this, you can set were wiped. To partially solve this, you can add init_on_free=1 to
CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1 your kernel command line. However, this has a performance cost.
to your kernel command line. However, this has a performance cost.
- Secret keys might still exist in CPU registers, in crypto - Secret keys might still exist in CPU registers, in crypto
accelerator hardware (if used by the crypto API to implement any of accelerator hardware (if used by the crypto API to implement any of
@ -428,11 +427,8 @@ API, but the filenames mode still does.
- Mandatory: - Mandatory:
- CONFIG_CRYPTO_ADIANTUM - CONFIG_CRYPTO_ADIANTUM
- Recommended: - Recommended:
- arm32: CONFIG_CRYPTO_CHACHA20_NEON
- arm32: CONFIG_CRYPTO_NHPOLY1305_NEON - arm32: CONFIG_CRYPTO_NHPOLY1305_NEON
- arm64: CONFIG_CRYPTO_CHACHA20_NEON
- arm64: CONFIG_CRYPTO_NHPOLY1305_NEON - arm64: CONFIG_CRYPTO_NHPOLY1305_NEON
- x86: CONFIG_CRYPTO_CHACHA20_X86_64
- x86: CONFIG_CRYPTO_NHPOLY1305_SSE2 - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2
- x86: CONFIG_CRYPTO_NHPOLY1305_AVX2 - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2

View file

@ -24,20 +24,16 @@ config FS_ENCRYPTION
# #
# Also note that this option only pulls in the generic implementations of the # Also note that this option only pulls in the generic implementations of the
# algorithms, not any per-architecture optimized implementations. It is # algorithms, not any per-architecture optimized implementations. It is
# strongly recommended to enable optimized implementations too. It is safe to # strongly recommended to enable optimized implementations too.
# disable these generic implementations if corresponding optimized
# implementations will always be available too; for this reason, these are soft
# dependencies ('imply' rather than 'select'). Only disable these generic
# implementations if you're sure they will never be needed, though.
config FS_ENCRYPTION_ALGS config FS_ENCRYPTION_ALGS
tristate tristate
imply CRYPTO_AES select CRYPTO_AES
imply CRYPTO_CBC select CRYPTO_CBC
imply CRYPTO_CTS select CRYPTO_CTS
imply CRYPTO_ECB select CRYPTO_ECB
imply CRYPTO_HMAC select CRYPTO_HMAC
imply CRYPTO_SHA512 select CRYPTO_SHA512
imply CRYPTO_XTS select CRYPTO_XTS
config FS_ENCRYPTION_INLINE_CRYPT config FS_ENCRYPTION_INLINE_CRYPT
bool "Enable fscrypt to use inline crypto" bool "Enable fscrypt to use inline crypto"