On 27/10/2020 07:59, Gilad Ben-Yossef wrote: > On Mon, Oct 26, 2020 at 9:04 PM Milan Broz <gmazyland@xxxxxxxxx> wrote: ... >> We had all of disk-IV inside dmcrypt before - but once it is partially moved into crypto API >> (ESSIV, EBOIV for now), it becomes much more complicated for user to select what he needs. >> >> I think we have no way to check that IV is available from userspace - it >> will report the same error as if block cipher is not available, not helping user much >> with the error. >> >> But then I also think we should add abstract dm-crypt options here (Legacy TrueCrypt modes, >> Bitlocker modes) that will select these crypto API configuration switches. >> Otherwise it will be only a complicated matrix of crypto API options... > > hm... just thinking out loud, but maybe the right say to go is to not > have a build dependency, > but add some user assistance code in cryptosetup that parses > /proc/crypto after failures to > try and suggest the user with a way forward? > > e.g. if eboiv mapping initiation fails, scan /proc/crypto and either > warn of a lack of AES > or, assuming some instance of AES is found, warn of lack of EBOIV. > It's a little messy > and heuristic code for sure, but it lives in a user space utility. > > Does that sound sane? Such an idea (try to parse /proc/crypto) is on my TODO list since 2009 :) I expected userspace kernel crypto API could help here, but it seems it is not the case. So yes, I think we need to add something like this in userspace. In combination with the kernel and dmcrypt target version, we could have a pretty good hint matrix for the user, instead of (literally) cryptic errors. (There is also a problem that device-mapper targets are losing detailed error state. We often end just with -EINVAL during table create ... and no descriptive log entry. And leaking info about encrypted devices activation failures to syslog is not a good idea either.) Anyway, this will not fix existing userspace that is not prepared for this kind of EBOIV missing fail, so Herbert's solution seems like the solution for this particular problem for now. (But I agree we should perhaps remove these build dependences in future completely...) Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
