loop's initial vector (=IV) calculation is based on the logical blocknumber (necessary for crypto). Copy your image to another medium with a different blocksize and the image will be broken. This flaw is known for a long time since 2.4.x, but the 2.4.x maintainers hesitated to correct it, since it will break any old images. I'd like to emphasize that this is the best point in time to fix that issue once and for all. Fix: Always use the same IV calculation, which can only be the smallest granulity available for blocksizes -> 512. http://mail.nl.linux.org/linux-crypto/2001-12/msg00000.html I'm told Adam J. Richter <adam@yggdrasil.com> has submitted patches for loop.c, but obviously his requests have been ignored.
Created attachment 55 [details] Adam J. Richter's Patch for 2.5.50
Ping Adam about the problem, as far as I'm concerned he's free to submit his loop patches to Linus.
Does anyone know the status of this patch? Does it fix the problem reported here so that the bug can be moved to the resolved state, or has patch made it to the mainline kernel tree so that the bug can be closed?
nothing has changed. this issue is still present. adam has a backward compatible patch, but it depends on other patches .. I'm not up-to-date if these patches have been submitted && accepted.
Created attachment 393 [details] trivial loop.c patch. based on hvr's 2.4.x version. This is the most trivial patch for this issue. Not backward compatible. See discussion.
I've attached a trivial patch for loop.c It is NOT backward compatible with any loop transformation which uses the IV information. However I think it is a feasible solution, since - Adam's changes to loop.c are too big to get accepted in the near future. There is no loop.c maintainer, and no one is working on splitting up Adam's patches. - To my knowledge there is no project which uses loop.c's IV information except for loop-AES and CryptoAPI. These two crypto projects have fixed this issue two years ago. Therefor their userbase will not be affected since they're using the new scheme already. So, my suggestion is to apply this dirty fix and go for a clean-up of loop.c after 2.6.0.
No. This will break existing crypto loop installations, making the existing encrypted image unreable. The only way to implement this is with a new flag that is set by losetup and keep the old behaviour by default.
I believe that this is fixed by patched from Andries Brouwer. http://marc.theaimsgroup.com/?l=linux-kernel&m=105620832631132&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=105648683103992&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=105715936912487&w=2
It is getting somewhat late :-) s/patched/patches/
this is correct. thanks for keeping track.