Re: A patch to loop.c for better cryption support

From: Ingo Rohloff (
Date: Sat Oct 14 2000 - 10:13:21 EST

> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:27 EST