Bug 192 - loop.c IV calculation is broken since 2.4.x
Summary: loop.c IV calculation is broken since 2.4.x
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P2 normal
Assignee: Jeff Sipek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-12-22 16:39 UTC by Fruhwirth Clemens
Modified: 2003-07-19 02:08 UTC (History)
0 users

See Also:
Kernel Version:
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Adam J. Richter's Patch for 2.5.50 (49.05 KB, patch)
2002-12-23 16:03 UTC, Fruhwirth Clemens
Details | Diff
trivial loop.c patch. based on hvr's 2.4.x version. (1.57 KB, patch)
2003-06-02 08:26 UTC, Fruhwirth Clemens
Details | Diff

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.

Note You need to log in before you can comment on or make changes to this bug.