On 20/07/2019 08:58, Eric Biggers wrote: > On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote: >> Also, I would like to avoid another "just because it is nicer" module dependence (XTS->XEX->ECB). >> Last time (when XTS was reimplemented using ECB) we have many reports with initramfs >> missing ECB module preventing boot from AES-XTS encrypted root after kernel upgrade... >> Just saying. (Despite the last time it was keyring what broke encrypted boot ;-) >> > > Can't the "missing modules in initramfs" issue be solved by using a > MODULE_SOFTDEP()? Actually, why isn't that being used for xts -> ecb already? > > (There was also a bug where CONFIG_CRYPTO_XTS didn't select CONFIG_CRYPTO_ECB, > but that was simply a bug, which was fixed.) Sure, and it is solved now. (Some systems with a hardcoded list of modules have to be manually updated etc., but that is just bad design). It can be done properly from the beginning. I just want to say that that switching to XEX looks like wasting time to me for no additional benefit. Fully implementing XTS does make much more sense for me, even though it is long-term the effort and the only user, for now, would be testmgr. So, there are no users because it does not work. It makes no sense to implement it, because there are no users... (sorry, sounds like catch 22 :) (Maybe someone can use it for keyslot encryption for keys not aligned to block size, dunno. Actually, some filesystem encryption could have use for it.) > Or "xts" and "xex" could go in the same kernel module xts.ko, which would make > this a non-issue. If it is not available for users, I really see no reason to introduce XEX when it is just XTS with full blocks. If it is visible to users, it needs some work in userspace - XEX (as XTS) need two keys, people are already confused enough that 256bit key in AES-XTS means AES-128... So the examples, hints, man pages need to be updated, at least. Milan
