On Tue, 10 Jul 2001, Jari Ruusu wrote:
> Herbert Valerio Riedel wrote:
> > On Tue, 10 Jul 2001, Dale Amon wrote:
> > > * BUG: block size problem
> > > Has a current work around, Herbert has stated
> > > he will soon have it fixed in code.
> > this one has been fixed, or better, I've already implemented a workaround
> > quite some weeks ago, it's been available in the cryptoapi branch, but
> > this one requires to modify the existing kernel loop.c module, (just like
> > loop-AES does, btw!!)
>
> Wrong! Loop-AES does not modify your kernel sources. It modifies a copy of
> your kernel's loop.c in its own compile directory.
sorry, I haven't made it clear enough, what I'm trying to say, which is:
both, loop-AES and the (optionally) applicable workaround-patch included
in the cryptoapi distribution, work, by modifying a loop.c
whether this loop.c is still located in the kernel source tree, or has
been copied out of it does not really care, it's just a minor detail IMHO.
both methods can be interchanged, it's just a matter of makefile rules and
use of scripts (n.b. I haven't implemented any automated way of
applying the workaround-patch to the kernel source or a copy of the
loop.c)
anyway, what's common in the end result, both packages lead to a loop.o,
and both require to use this one instead of the original loop.o, because
all this loop.o variants are meant as _replacements_ of the original
loop.o (there are resource conflicts, cause both claim to provide the
/dev/loop? devices)
so actually you can't use more than 1 of the 3 loop.o flavours, vanilla
loop.o, loop-AES and loop-cryptoapi at the same time.
while I'm at it, I'd like to discuss how the loop-AES and cryptoapi differ
in modifying loop.c (n.b. that's the branched int-patch variant I'm
working on, so this comparison may be a bit biased, but I'll try to avoid
it, please correct me where I fail to) btw, the discussion is based on the
2.4.x kernel.
loop-AES (loop-AES-v1.3c/loop.c-2.4.diff):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the core loop.c changes consists in a radical change of the blocksize
dependent IV calculation, the changes are kept to a minimum (which can be
regarded a good thing), it has also been taken care to avoid overflows in
the multiply/divisions involved.
what I'm not sure about, is the reason of the addition of
if(S_ISREG(inode->i_mode)) bs = BLOCK_SIZE;
since BLOCK_SIZE is defined to be (1 << 10) in fs.h
finally, code to initialize the aes module have been hardcoded into loop.c
this is IMHO a rather static approach, since unflexible, if it wasn't for
this one, the modified loop.c could be easily used as drop in replacament
for the cryptoapi, but nevertheless it might be possible to use cryptoapi
with minor adaptions with the loop-AES modified loop-AES' loop.o. I'll
investigate this one a little bit more, this might finally allow for
backporting the cryptoapi to 2.2 by making use of jari's 2.2
modifications.
cryptoapi (loop-iv-2.4.6.patch):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compared to the simple approach to just adapt loop.c to change from var
blocksize to a fixed 512byte calculation base, I've tried to do a more
generic one, conserving the old IV calculation scheme for backward
compatibility
(actually, my first fix was to do just as loop-AES does, to simply replace
the variable blocksize IV calcualtion, by 512 byte IV calcs, but when
trying to submit this one to the actual kernel developers concerned with
maintaining the loop.c driver, it was rejected, due to its non-backward
compatible approach, so I agreed to design a more flexible approach, which
is why the loop.c modification becomes a bit more complicated at the first
sight -- btw, I haven't officially submitted the new approach yet for
kernel inclusion since then again...)
ok, now for what I've actually done:
I've added an variable to loop_device, in order to set the requested
IV calculation mode, for old code (i.e. filter functions) nothing changes,
they still get the original calculation methode, and everyones happy.
but for new code, aware of the new interface property, it is able to
choose among LO_IV_MODE_DEFAULT and LO_IV_MODE_SECTOR (512byte based)
maybe in future there is need for other block sizes (2048 for CDROM
devices for instance). based on this property, all IV calculations are
affected to either conform to the device block size or to a fixed 512
block size.
except for this, there is nothing crypto specific added (no
initialization of any cryptographic module or whatsoever)
how the rest compares
~~~~~~~~~~~~~~~~~~~~~
when comparing both packages, I realized they are quite similiar in shape;
*) both modify a loop.c,
*) both have a 'glue' layer for providing the transfer filter
function to loop device, i.e. aes-glue.c 'module' maps to
cryptoloop.c
*) loop-AES' aes.c can be seen as specialized case (don't take me too
literal here please) of an AES cipher. whereas the cryptapi's loop
filter makes use of the cryptoapi framework to chose among the
available (not even required to be known in advance) cipher
algorithms.
the last item shows alrady where the packages have their main difference;
the cryptoapi approach tries to be flexible and let the user chose what he
wants, wheras the loop-AES approach is more to be seen as a specialized
case, offering only the most essential features in a non-modular way
(I'm refering to the fact, that loop-AES features a loop.o which get's
linked in the aes-glue and the actual aes cipher, whereas the cryptoapi
subdivides every reasonable component into it's own module -- it's
completely ok for loop-AES to chose this monolithic approach, since there
actually no need for splitting it up, due to the restricte set of
applications, i.e. only one cipher used for loop filter only)
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: hvr@xxxxxxxxxx / Finger hvr@xxxxxxx for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
