hello!
short version:
this is the international crypto patch, which is built outside of
the kernel source tree. you don't even have to reboot (unless your
kernel didn't have loop devices enabled, or some other unthought
situation exists... :)
As a response to Jari's loop-AES crypto filter for the loop back
device, which claims to be hassle free since no kernel modification is
needed; I've repackaged the all known international crypto patch,
which according to some people suffers from the need to patch the
kernel in order to make use of it and thus may not be ever get into
the kernel since there are still some countries where laws don't
support an individuals need for privacy.
This (re)package has only one major drawback, crypto can only built as
modules so far and it supports only kernel 2.4.3 and later so far...
If you are interested you can get it from
http://www.hvrlab.org/pub/crypto/cryptoapi-2.4.3-hvr4.tar.gz
...as usual, backup your data before playing around with it... :-)
ps: there is an optional patch against loop.[ch] contained, which
fixes current IV calculation bugs and introduces a selectable sector
based IV calculation mode.
greetings,
--
Herbert Valerio Riedel / Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Herbert Valerio Riedel wrote:
> short version:
> this is the international crypto patch, which is built outside of
> the kernel source tree. you don't even have to reboot (unless your
> kernel didn't have loop devices enabled, or some other unthought
> situation exists... :)
>
> As a response to Jari's loop-AES crypto filter for the loop back
> device, which claims to be hassle free since no kernel modification is
> needed; I've repackaged the all known international crypto patch,
> which according to some people suffers from the need to patch the
> kernel in order to make use of it and thus may not be ever get into
> the kernel since there are still some countries where laws don't
> support an individuals need for privacy.
>
> This (re)package has only one major drawback, crypto can only built as
> modules so far and it supports only kernel 2.4.3 and later so far...
linux-2.4.3-cryptoapi-hvr4/drivers/block/loop.c lines 270...279 after your
kernel patch:
static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long offset, unsigned long size)
{
char *kaddr;
unsigned long count = desc->count;
struct lo_read_data *p = (struct lo_read_data*)desc->buf;
struct loop_device *lo = p->lo;
unsigned long IV = loop_get_iv(lo, (page->index * PAGE_CACHE_SIZE + offset - lo->lo_offset) >> LO_IV_SECTOR_BITS);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
if (size > count)
size = count;
Have you tested that code with partitions or files that are larger than
4 gigs? On systems where int is 32 bits, that computation overflows.
If you want 512 byte based IV computation without modifying your kernel at
all, you can use the loop.o module from my loop-AES package. I haven't tried
using your modules based cryptoapi and my loop-AES drivers together, but I
don't see any obvious reason why they couldn't be used simultaneously.
My loop-AES package is here:
http://members.surfeu.fi/ce6c8edf/loop-AES-v1.1b.tar.bz2
md5sum 61e521a383ce9a90c3f7b98bcf789813
Regards,
Jari Ruusu <[email protected]>
hi,
On Tue, 24 Apr 2001, Jari Ruusu wrote:
> linux-2.4.3-cryptoapi-hvr4/drivers/block/loop.c lines 270...279 after your
> kernel patch:
>
> static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long offset, unsigned long size)
> {
> char *kaddr;
> unsigned long count = desc->count;
> struct lo_read_data *p = (struct lo_read_data*)desc->buf;
> struct loop_device *lo = p->lo;
> unsigned long IV = loop_get_iv(lo, (page->index * PAGE_CACHE_SIZE + offset - lo->lo_offset) >> LO_IV_SECTOR_BITS);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> if (size > count)
> size = count;
>
> Have you tested that code with partitions or files that are larger than
> 4 gigs? On systems where int is 32 bits, that computation overflows.
you're right, I actually had it right in the first place, but stupidly
rewrote it to overflow C:-)
it should have been more or less:
unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));
I'll be fixed in cryptoapi-2.4.3-hvr6 (see http://www.hvrlab.org/crypto/)
oh, and btw, it should only concern file backed loop's... block devices,
as partitions, should have worked fine...
> If you want 512 byte based IV computation without modifying your kernel at
> all, you can use the loop.o module from my loop-AES package. I haven't tried
> using your modules based cryptoapi and my loop-AES drivers together, but I
> don't see any obvious reason why they couldn't be used simultaneously.
erm... I've looked at your patch... you do just the same thing as I do, as
it concerns 'changing the kernel'... but you do it in a 'static' way... I
want it to be changeable at runtime... and letting the way open to add
more IV calculation variants in the future, which every filter can choose
among at initialization...
> Linux-crypto: cryptography in and on the Linux system
> Archive: http://mail.nl.linux.org/linux-crypto/
greetings,
--
Herbert Valerio Riedel / Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Herbert Valerio Riedel wrote:
> On Tue, 24 Apr 2001, Jari Ruusu wrote:
> > Have you tested that code with partitions or files that are larger than
> > 4 gigs? On systems where int is 32 bits, that computation overflows.
> you're right, I actually had it right in the first place, but stupidly
> rewrote it to overflow C:-)
>
> it should have been more or less:
>
> unsigned long IV = loop_get_iv(lo,
> page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
> + (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));
I hope not exactly like that. What happens when "lo->lo_offset" is larger
than "offset". Oops. Besides, the + operator takes precedence over the >>
operator on the third line.
> > If you want 512 byte based IV computation without modifying your kernel at
> > all, you can use the loop.o module from my loop-AES package. I haven't tried
> > using your modules based cryptoapi and my loop-AES drivers together, but I
> > don't see any obvious reason why they couldn't be used simultaneously.
>
> erm... I've looked at your patch... you do just the same thing as I do, as
> it concerns 'changing the kernel'... but you do it in a 'static' way... I
> want it to be changeable at runtime... and letting the way open to add
> more IV calculation variants in the future, which every filter can choose
> among at initialization...
Have you ever observed the sizes of the transfer requests? The sizes of
transfer requests change on the fly (and I'm not not talking about the last
partial block of a file). Meaning, any IV computation that depends on the
block size of a filesystem, is broken and must die! We do not have an option
here.
Just for the record, loop-AES package does 512 byte based IV and does not
care about filesystem block size. loop-AES package does not change kernel
sources and is almost immune to kernel source changes made by distro
vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.
# make LINUX_SOURCE=/usr/src/linux-2.2.19aa2
cd /usr/src/linux-2.2.19aa2 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.2.19aa2'
make -C /root/loop-AES-v1.1b CFLAGS="-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c aes-glue.c -o aes-glue.o
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.2.19aa2/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.2.diff || cp loop.c-2.2.original patched-loop.c
patching file `patched-loop.c'
patch -p0 -l < loop.c-2.2.diff
patching file `patched-loop.c'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.2.19aa2/block
cp -p loop.o /lib/modules/2.2.19aa2/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.2.19aa2'
Result: Working loop.o module with AES cipher built in, and 512 byte IV.
Here I'm building loop-AES on 2.2.19aa2-bad where I intentionally changed
loop.c in a way that makes the loop-AES patch fail, but Makefile has a
working plan B.
# make LINUX_SOURCE=/usr/src/linux-2.2.19aa2-bad
cd /usr/src/linux-2.2.19aa2-bad && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.2.19aa2-bad'
make -C /root/loop-AES-v1.1b CFLAGS="-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c aes-glue.c -o aes-glue.o
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.2.19aa2-bad/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.2.diff || cp loop.c-2.2.original patched-loop.c
patching file `patched-loop.c'
Hunk #1 FAILED at 256.
1 out of 2 hunks FAILED -- saving rejects to patched-loop.c.rej
patch -p0 -l < loop.c-2.2.diff
patching file `patched-loop.c'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.2.19aa2/block
cp -p loop.o /lib/modules/2.2.19aa2/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.2.19aa2-bad'
Result: Working loop.o module with AES cipher built in, and 512 byte IV.
Here I'm building loop-AES on vanilla 2.4.3-ac14.
# make LINUX_SOURCE=/usr/src/linux-2.4.3-ac14
cd /usr/src/linux-2.4.3-ac14 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.4.3-ac14'
make -C /root/loop-AES-v1.1b CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c aes-glue.c -o aes-glue.o
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.4.3-ac14/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.4.diff || cp loop.c-2.4.original patched-loop.c
patching file `patched-loop.c'
patch -p0 -l < loop.c-2.4.diff
patching file `patched-loop.c'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.4.3-ac14/block
cp -p loop.o /lib/modules/2.4.3-ac14/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac14'
Result: Working loop.o module with AES cipher built in, and 512 byte IV.
Here I'm building loop-AES on 2.4.3-ac14-hvr5 with your kernel patch
cryptoapi-2.4.3-hvr5/doc/loop-iv-2.4.3.patch applied, which makes the
loop-AES patch fail, but Makefile has a working plan B.
# make LINUX_SOURCE=/usr/src/linux-2.4.3-ac14-hvr5
cd /usr/src/linux-2.4.3-ac14-hvr5 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.4.3-ac14-hvr5'
make -C /root/loop-AES-v1.1b CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c aes-glue.c -o aes-glue.o
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.4.3-ac14-hvr5/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.4.diff || cp loop.c-2.4.original patched-loop.c
patching file `patched-loop.c'
Hunk #1 FAILED at 181.
Hunk #2 FAILED at 232.
Hunk #3 FAILED at 466.
Hunk #4 succeeded at 519 (offset 17 lines).
Hunk #5 succeeded at 1000 (offset 1 line).
Hunk #6 succeeded at 1030 (offset 17 lines).
3 out of 6 hunks FAILED -- saving rejects to patched-loop.c.rej
patch -p0 -l < loop.c-2.4.diff
patching file `patched-loop.c'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.4.3-ac14/block
cp -p loop.o /lib/modules/2.4.3-ac14/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac14-hvr5'
Result: Working loop.o module with AES cipher built in, and 512 byte IV.
Regards,
Jari Ruusu <[email protected]>
hello!
On Thu, 26 Apr 2001, Jari Ruusu wrote:
> Herbert Valerio Riedel wrote:
> > On Tue, 24 Apr 2001, Jari Ruusu wrote:
> > it should have been more or less:
> >
> > unsigned long IV = loop_get_iv(lo,
> > page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
> > + (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));
> I hope not exactly like that. What happens when "lo->lo_offset" is larger
> than "offset". Oops. Besides, the + operator takes precedence over the >>
> operator on the third line.
...you are right again :-)
do you have any objections about...
unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset >> LO_IV_SECTOR_BITS)
- (lo->lo_offset >> LO_IV_SECTOR_BITS));
...then? ;-)
the assumption is, offset % LO_IV_SECTOR_BITS == 0
this calculation may overflow anyway... for file sizes around terabytes or
so I guess... but another thing is, that every IV calculation should
overflow at the same boundary... since it's just an IV value...
(maybe that calculation should be done in a 64bit domain anyway)
> Have you ever observed the sizes of the transfer requests? The sizes of
> transfer requests change on the fly (and I'm not not talking about the last
> partial block of a file). Meaning, any IV computation that depends on the
> block size of a filesystem, is broken and must die! We do not have an option
> here.
I know that issue, I've already pointed that out some time ago, but there
are compatibility problems as well, at first I thought the international
crypto patch was the only filter to make use of that IV, but then I
learned there were a few others as well...
(btw, the int crypto patch had the compatibility option for absolute block
numbers for quite some time too... just for the sake of compatibility...)
and btw, many people seem to be quite happy with their non-512 based IV
encrypted volumes... so why forcing them to switch?
btw, depending on the filesystem using the loop device, and the underlying
file or device, the transfer requests size may be constant... e.g. at 4k
blocks... but other filesystems, such as XFS do have different sections
with different blocksizes... they clearly break things...
breaking up transfers into 512 bytes _everytime_ isn't a solution
either... it is unefficient, especially for filters not making use of the
IV at all...
> Just for the record, loop-AES package does 512 byte based IV and does not
> care about filesystem block size. loop-AES package does not change kernel
> sources and is almost immune to kernel source changes made by distro
> vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.
:-)
what I'm trying to say, you just take the kernel's loop.c, patch it to do
512 byte IV calculation (and 512 byte requests) and requiring the user to
load it... you actually require the user to not have the loop.c device
compiled into the kernel... and when your loop module is loaded into the
kernel the stock loop module can't be at the same time... it's an XOR
solution...
[..build log...]
> Here I'm building loop-AES on 2.2.19aa2-bad where I intentionally changed
> loop.c in a way that makes the loop-AES patch fail, but Makefile has a
> working plan B.
[..build log2..]
>
> Result: Working loop.o module with AES cipher built in, and 512 byte IV.
>
> Here I'm building loop-AES on vanilla 2.4.3-ac14.
>
[...yet another build log...]
>
> Result: Working loop.o module with AES cipher built in, and 512 byte IV.
>
> Here I'm building loop-AES on 2.4.3-ac14-hvr5 with your kernel patch
> cryptoapi-2.4.3-hvr5/doc/loop-iv-2.4.3.patch applied, which makes the
> loop-AES patch fail, but Makefile has a working plan B.
[...guess what...]
> Result: Working loop.o module with AES cipher built in, and 512 byte IV.
two different minds -- two different approaches :-)
greetings,
--
Herbert Valerio Riedel / Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Herbert Valerio Riedel wrote:
> do you have any objections about...
>
> unsigned long IV = loop_get_iv(lo,
> page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
> + (offset >> LO_IV_SECTOR_BITS)
> - (lo->lo_offset >> LO_IV_SECTOR_BITS));
>
> ...then? ;-)
Looks fine.
> > Have you ever observed the sizes of the transfer requests? The sizes of
> > transfer requests change on the fly (and I'm not not talking about the last
> > partial block of a file). Meaning, any IV computation that depends on the
> > block size of a filesystem, is broken and must die! We do not have an option
> > here.
> I know that issue, I've already pointed that out some time ago, but there
> are compatibility problems as well, at first I thought the international
> crypto patch was the only filter to make use of that IV, but then I
> learned there were a few others as well...
> (btw, the int crypto patch had the compatibility option for absolute block
> numbers for quite some time too... just for the sake of compatibility...)
>
> and btw, many people seem to be quite happy with their non-512 based IV
> encrypted volumes... so why forcing them to switch?
They are time bombs. Can you be sure that upper layers in the kernel won't
pass a transfer size that is not same as filesystem block size? I have seen
that happen. If you haven't, you have been lucky. I'd rather not depend on
luck.
> btw, depending on the filesystem using the loop device, and the underlying
> file or device, the transfer requests size may be constant... e.g. at 4k
> blocks... but other filesystems, such as XFS do have different sections
> with different blocksizes... they clearly break things...
>
> breaking up transfers into 512 bytes _everytime_ isn't a solution
> either... it is unefficient, especially for filters not making use of the
> IV at all...
There is no point to limit transfers to 512 bytes. Transfer function just
needs to increment the original IV and reinitialize the cipher block
chaining process after every 512 bytes transferred.
> > Just for the record, loop-AES package does 512 byte based IV and does not
> > care about filesystem block size. loop-AES package does not change kernel
> > sources and is almost immune to kernel source changes made by distro
> > vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.
> :-)
>
> what I'm trying to say, you just take the kernel's loop.c, patch it to do
> 512 byte IV calculation (and 512 byte requests) and requiring the user to
> load it... you actually require the user to not have the loop.c device
> compiled into the kernel... and when your loop module is loaded into the
> kernel the stock loop module can't be at the same time... it's an XOR
> solution...
Transfer size is not altered, see previous comment. No need for user to load
the loop.o module, kmod does that automatically if CONFIG_KMOD=y. Build
instructions in a README file say that loop must be disabled the kernel
config for this externally compiled loop.o to work at all.
> two different minds -- two different approaches :-)
Ok.
Regards,
Jari Ruusu <[email protected]>