[lkml]   [2001]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Announce: cryptoapi-2.4.3 [aka international crypto (non-)patch]

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,
+ (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));

I'll be fixed in cryptoapi-2.4.3-hvr6 (see

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:

Herbert Valerio Riedel / Finger for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.126 / U:7.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site