Messages in this thread | | | Date | Sat, 14 Oct 2000 15:13:21 +0000 | From | Ingo Rohloff <> | Subject | Re: A patch to loop.c for better cryption support |
| |
> So, the only provision that needs to be made to ensure backwards > compatibility (both with the kerneli patch and other modules that still > use absolute block numbers) is a way to switch between the new approach > and the old, defaulting to the new. The easiest way to do this, IMO, is > to allocate a new field 'encryption_chunk_size' or so from the set of > reserved words in struct loop_info. One might even get away with a > single bit, indicating whether to use 512 byte blocks or underlying > blocks as encryption chunks. Maybe lo_flags could be used when it > becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or > so. Then teach losetup to set this bit unless instructed not to.
Yes that's the start. I have to study loop.c more intensivly, because I think I found at least two more trap doors. (It's amazing that it works at all :-) )
Look at the line
if (size > len) size = len
This seems to be horrible wrong... A CBC chain always has to decrypt/encrypt a whole block otherwise the data my be irrecoverable. (With the sector approach it works, because len is sectors << 9 ...)
And also
block = current_request->sector / (blksize >> 9); offset = (current_request->sector % (blksize >> 9)) << 9;
The whole operation will go wrong if offset != 0 .
so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |