linux-ext4 - Re: [PATCH] fscrypto: remove unneeded Kconfig dependencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161024211727.GB83082@google.com>
Date:   Mon, 24 Oct 2016 14:17:27 -0700
From:   Eric Biggers <ebiggers@...gle.com>
To:     Richard Weinberger <richard@....at>
Cc:     linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net, tytso@....edu,
        jaegeuk@...nel.org
Subject: Re: [PATCH] fscrypto: remove unneeded Kconfig dependencies

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html