SHA256 and ENCRYPTED_KEYS are not needed. CTR shouldn't be needed
either, but I left it for now because it was intentionally added by
commit 71dea01ea2ed ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4
encryption is enabled"). So it sounds like there may be a dependency
problem elsewhere, which I have not been able to identify specifically,
that must be solved before CTR can be removed.
Signed-off-by: Eric Biggers <[email protected]>
---
fs/crypto/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
index 92348fa..f514978 100644
--- a/fs/crypto/Kconfig
+++ b/fs/crypto/Kconfig
@@ -8,9 +8,7 @@ config FS_ENCRYPTION
select CRYPTO_XTS
select CRYPTO_CTS
select CRYPTO_CTR
- select CRYPTO_SHA256
select KEYS
- select ENCRYPTED_KEYS
help
Enable encryption of files and directories. This
feature is similar to ecryptfs, but it is more memory
--
2.8.0.rc3.226.g39d4020
On 24.10.2016 22:17, Eric Biggers wrote:
> SHA256 and ENCRYPTED_KEYS are not needed. CTR shouldn't be needed
> either, but I left it for now because it was intentionally added by
> commit 71dea01ea2ed ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4
> encryption is enabled"). So it sounds like there may be a dependency
> problem elsewhere, which I have not been able to identify specifically,
> that must be solved before CTR can be removed.
>
> Signed-off-by: Eric Biggers <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
FWIW, Strictly speaking we could also get rid of the dependency on BLOCK.
Only very few functions in fs/crypto/crypto.c use block specific functions,
these could be placed in a different file.
The use case would be very small systems with UBIFS and encrypted files.
i.e. kexec() style bootloaders.
Thanks,
//richard
On Mon, Oct 24, 2016 at 10:41:08PM +0200, Richard Weinberger wrote:
> FWIW, Strictly speaking we could also get rid of the dependency on BLOCK.
> Only very few functions in fs/crypto/crypto.c use block specific functions,
> these could be placed in a different file.
> The use case would be very small systems with UBIFS and encrypted files.
> i.e. kexec() style bootloaders.
>
> Thanks,
> //richard
Yes, that makes sense if UBIFS is going to be using the code too. Feel free to
propose a patch. As I understand it, the assumption would be that if a
filesystem needs the block-specific functions in fs/crypto/, then it itself
would necessarily already depend on CONFIG_BLOCK. It should work to just
conditionally compile the block-specific functions based on CONFIG_BLOCK, either
via #ifdefs or by having a separate file like fs/crypto/block.c and putting
'fscrypto-$(CONFIG_BLOCK) += block.o' in fs/crypto/Makefile. The separate file
sounds preferable.
Eric
On Mon, Oct 24, 2016 at 01:17:06PM -0700, Eric Biggers wrote:
> SHA256 and ENCRYPTED_KEYS are not needed. CTR shouldn't be needed
> either, but I left it for now because it was intentionally added by
> commit 71dea01ea2ed ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4
> encryption is enabled"). So it sounds like there may be a dependency
> problem elsewhere, which I have not been able to identify specifically,
> that must be solved before CTR can be removed.
>
> Signed-off-by: Eric Biggers <[email protected]>
Applied, thanks.
- Ted