> 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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:27 EST