Bug 192

Summary: loop.c IV calculation is broken since 2.4.x
Product: IO/Storage Reporter: Fruhwirth Clemens (clemens)
Component: Block LayerAssignee: Jeff Sipek (jeffpc)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal    
Priority: P2    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: --- Bisected commit-id:
Attachments: Adam J. Richter's Patch for 2.5.50
trivial loop.c patch. based on hvr's 2.4.x version.

Description Fruhwirth Clemens 2002-12-22 16:39:26 UTC 
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.
Comment 1 Fruhwirth Clemens 2002-12-23 16:03:53 UTC 
Created attachment 55 [details]
Adam J. Richter's Patch for 2.5.50
Comment 2 Jens Axboe 2002-12-27 12:19:26 UTC 
Ping Adam about the problem, as far as I'm concerned he's free to submit his
loop patches to Linus.
Comment 3 Stacy Woods 2003-04-10 12:59:14 UTC 
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?
Comment 4 Fruhwirth Clemens 2003-04-10 16:13:38 UTC 
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.
Comment 5 Fruhwirth Clemens 2003-06-02 08:26:24 UTC 
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.
Comment 6 Fruhwirth Clemens 2003-06-02 08:34:05 UTC 
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.
Comment 7 Andi Kleen 2003-06-20 02:25:57 UTC 
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.
Comment 9 Jeff Sipek 2003-07-17 22:31:14 UTC 
It is getting somewhat late :-)

s/patched/patches/
Comment 10 Fruhwirth Clemens 2003-07-19 02:08:04 UTC 
this is correct. thanks for keeping track.