| Message ID | 1477340226-144248-1-git-send-email-ebiggers@google.com |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
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 <ebiggers@google.com> Reviewed-by: Richard Weinberger <richard@nod.at> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <ebiggers@google.com> Applied, thanks. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <ebiggers@google.com> --- fs/crypto/Kconfig | 2 -- 1 file changed, 2 deletions(-)