Cryptoapi on 2.4.17 (2 patches)

Cryptoapi on 2.4.17 (2 patches)

[Zygo Blaxell]

[-- Attachment #1.1: Type: text/plain, Size: 1124 bytes --]

I have two patches, one for cryptoAPI (current CVS) and one for the
Linux kernel (2.4.17).  

The cryptoapi patch fixes a silly symbol name bug.  The
patch for the Linux kernel changes the default lo_iv_mode to
LO_IV_MODE_SECTOR--otherwise, the patch is just a straightforward port
of the patch in cryptoapi/doc in cryptoavi CVS.

I noticed that there doesn't seem to be a way to set lo_iv_mode from
user-space, not even with a module or kernel command-line parameter.
Is this just one of those features that isn't implemented yet, or did
I miss something?

The patches seem to work:  I can swap on an rc6 encrypted partition
using the patches, and I can create an ext2 filesystem on an rc6 loopback
file, copy some data to it, unmount, losetup -d, losetup -e, mount it
again, and _still access the data afterwards_.  Whee!

This still doesn't completely work for encrypted swap because somebody
(who shall remain nameless, but whose name rhymes with socks) seems to
have "lost" the kreclaimd kernel thread.  I thought I would try to get 
someone else to look at this before tackling that problem...


[-- Attachment #1.2: p1 --]
[-- Type: text/plain, Size: 1519 bytes --]

? tests/.deps
? tests/Makefile
? tests/Makefile.in
Index: api/cryptoloop.c
===================================================================
RCS file: /cvsroot/cryptoapi/cryptoapi/api/cryptoloop.c,v
retrieving revision 1.4
diff -u -r1.4 cryptoloop.c
--- api/cryptoloop.c	2001/12/14 23:38:49	1.4
+++ api/cryptoloop.c	2001/12/26 21:30:57
@@ -44,7 +44,7 @@
 # error you need at least kernel 2.4.3 -- unless you know exacty what you are doing
 #endif
 
-#if !defined(LOOP_IV_SECTOR_SIZE)
+#if !defined(LO_IV_SECTOR_SIZE)
 # error you need to to patch your loop.c driver
 #endif
 
@@ -85,10 +85,10 @@
   struct cipher_context *cx;
 
   /* encryption breaks for non sector aligned offsets */
-  if (info->lo_offset % LOOP_IV_SECTOR_SIZE) 
+  if (info->lo_offset % LO_IV_SECTOR_SIZE) 
     goto out;
 
-  lx->blocksize = LOOP_IV_SECTOR_SIZE;
+  lx->blocksize = LO_IV_SECTOR_SIZE;
   lx->debug = 0;
 
   strncpy(cipher, info->lo_name, LO_NAME_SIZE);
@@ -163,7 +163,7 @@
     out = raw_buf;
   }
 
-  IV /= blocksize / LOOP_IV_SECTOR_SIZE;
+  IV /= blocksize / LO_IV_SECTOR_SIZE;
 
 #if defined(CRYPTOLOOP_DEBUG)
   if (lx->debug)
@@ -203,7 +203,7 @@
   switch (cmd) {
   case CRYPTOLOOP_SET_BLKSIZE:
     printk (KERN_DEBUG "cryptoloop: switch to blocksize %d requested\n", *arg_int);
-    if (*arg_int >= 0 && (*arg_int % LOOP_IV_SECTOR_SIZE == 0))
+    if (*arg_int >= 0 && (*arg_int % LO_IV_SECTOR_SIZE == 0))
       {
         lx->blocksize = *arg_int;
         err = 0;

[-- Attachment #1.3: p2 --]
[-- Type: text/plain, Size: 3244 bytes --]

--- /home/zblaxell/linux/p3-laptop/kernel-source-2.4.17-zb-p3-laptop-zb2001122605/drivers/block/loop.c	Fri Dec 21 12:41:53 2001
+++ drivers/block/loop.c	Wed Dec 26 13:59:05 2001
@@ -36,6 +36,9 @@
  * Al Viro too.
  * Jens Axboe <axboe@suse.de>, Nov 2000
  *
+ * Fixed and made IV calculation customizable by lo_iv_mode
+ * Herbert Valerio Riedel <hvr@gnu.org>, Apr 2001
+ *
  * Still To Fix:
  * - Advisory locking is ignored here. 
  * - Should use an own CAP_* category instead of CAP_SYS_ADMIN 
@@ -168,6 +171,43 @@
 					lo->lo_device);
 }
 
+static inline int loop_get_bs(struct loop_device *lo)
+{
+	int bs = 0;
+
+	if (blksize_size[MAJOR(lo->lo_device)])
+		bs = blksize_size[MAJOR(lo->lo_device)][MINOR(lo->lo_device)];
+	if (!bs)
+		bs = BLOCK_SIZE;	
+
+	return bs;
+}
+
+static inline unsigned long loop_get_iv(struct loop_device *lo,
+					unsigned long sector)
+{
+	unsigned long offset, IV;
+	int bs;
+
+	switch (lo->lo_iv_mode) {
+		case LO_IV_MODE_SECTOR:
+			IV = sector + (lo->lo_offset >> LO_IV_SECTOR_BITS);
+			break;
+
+		default:
+			printk (KERN_WARNING "loop: unexpected lo_iv_mode\n");
+		case LO_IV_MODE_DEFAULT:
+			bs = loop_get_bs(lo);
+			IV = sector / (bs >> 9) + lo->lo_offset / bs;
+			offset = ((sector % (bs >> 9)) << 9) + lo->lo_offset % bs;
+			if (offset >= bs)
+				IV++;
+			break;
+	}
+
+	return IV;
+}
+
 static int lo_send(struct loop_device *lo, struct buffer_head *bh, int bsize,
 		   loff_t pos)
 {
@@ -186,7 +226,7 @@
 	len = bh->b_size;
 	data = bh->b_data;
 	while (len > 0) {
-		int IV = index * (PAGE_CACHE_SIZE/bsize) + offset/bsize;
+                unsigned long IV = loop_get_iv(lo, (pos - lo->lo_offset) >> LO_IV_SECTOR_BITS);
 		int transfer_result;
 
 		size = PAGE_CACHE_SIZE - offset;
@@ -244,7 +284,10 @@
 	unsigned long count = desc->count;
 	struct lo_read_data *p = (struct lo_read_data*)desc->buf;
 	struct loop_device *lo = p->lo;
-	int IV = page->index * (PAGE_CACHE_SIZE/p->bsize) + offset/p->bsize;
+	unsigned long IV = loop_get_iv(lo,
+		((page->index <<  (PAGE_CACHE_SHIFT - LO_IV_SECTOR_BITS))
+		+ (offset >> LO_IV_SECTOR_BITS)
+		- (lo->lo_offset >> LO_IV_SECTOR_BITS)));
 
 	if (size > count)
 		size = count;
@@ -284,32 +327,6 @@
 	return desc.error;
 }
 
-static inline int loop_get_bs(struct loop_device *lo)
-{
-	int bs = 0;
-
-	if (blksize_size[MAJOR(lo->lo_device)])
-		bs = blksize_size[MAJOR(lo->lo_device)][MINOR(lo->lo_device)];
-	if (!bs)
-		bs = BLOCK_SIZE;	
-
-	return bs;
-}
-
-static inline unsigned long loop_get_iv(struct loop_device *lo,
-					unsigned long sector)
-{
-	int bs = loop_get_bs(lo);
-	unsigned long offset, IV;
-
-	IV = sector / (bs >> 9) + lo->lo_offset / bs;
-	offset = ((sector % (bs >> 9)) << 9) + lo->lo_offset % bs;
-	if (offset >= bs)
-		IV++;
-
-	return IV;
-}
-
 static int do_bh_filebacked(struct loop_device *lo, struct buffer_head *bh, int rw)
 {
 	loff_t pos;
@@ -677,6 +694,7 @@
 	lo->lo_backing_file = file;
 	lo->transfer = NULL;
 	lo->ioctl = NULL;
+	lo->lo_iv_mode = LO_IV_MODE_SECTOR;
 	figure_loop_size(lo);
 	lo->old_gfp_mask = inode->i_mapping->gfp_mask;
 	inode->i_mapping->gfp_mask = GFP_NOIO;

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Cryptoapi on 2.4.17 (2 patches)

[Herbert Valerio Riedel]

hello!

On Wed, 2001-12-26 at 23:03, Zygo Blaxell wrote:
> I have two patches, one for cryptoAPI (current CVS) and one for the
> Linux kernel (2.4.17).  
first of all, thanks for getting involved! :-)
 
> The cryptoapi patch fixes a silly symbol name bug.  The
well, that's due to the WIP state of the CVS... I was in the midst of
back-porting the development I did for the new int. patches at
http://www.kernel.org/pub/linux/kernel/people/hvr/testing/
when this time-consuming christmas event started becoming unignorable...
C;-)
 
> patch for the Linux kernel changes the default lo_iv_mode to
> LO_IV_MODE_SECTOR--otherwise, the patch is just a straightforward port
> of the patch in cryptoapi/doc in cryptoavi CVS.

 
> I noticed that there doesn't seem to be a way to set lo_iv_mode from
> user-space, not even with a module or kernel command-line parameter.
> Is this just one of those features that isn't implemented yet, or did
> I miss something?
the 'unimplemented'-choice applies;
but there's more... I'm glad you picked up the issue again, since it was
again starting to fall into oblivion... :-/

there are two different approaches, the first one I tried, was the one
seen in the cryptoapi-packaging, i.e. backward compatible; un-aware
loop-filters would get the old (broken) iv metric, while aware filters
could aktivate the 512-byte metric...
this approach was deemed an ugly 'toothpaste-back-to-tube' approach, but
it tried not to break old filters...
a few weeks ago, I retried to bring the issue on, in order to get the
patches somehow included into the mainstream-kernel; all parties agreed
that we could as well break the old iv-mode, and just default to the
better 'new' one... that way old filters may break the on-disk format,
but they will automatically become iv-safe; and if one really cares, you
can calculate the old iv from the new iv (just see the new int.patch and
cryptoloop_cfg below...)... BUT... as of now (2.4.17), the kernel still
uses the old IV scheme... it seems I'm not very good at being annoying
enough in order to get patches into the kernel... ;-)

well, if you take a look at the above mentioned testing-directory,
you'll find a cryptoloop_cfg.c which is some kind of user-space tool for
controlling the iv metric somewhat... it's more or less a hack, which
only works (if at all) when used in conjunction with the loop-hvr patch
(and the latest patch-int in that directory) the tool's provided for
converting your old non-512-iv metric encrypted volumes to more flexible
'atomar-sector-sized'-iv encrypted ones by doing something like
(untested --> make backups before trying it at home... or keep both
pieces...)

# losetup -e ...  /dev/loop0 /dev/blockdev
# cryptoloop_cfg /dev/loop0 --set-blksize 0
    if you happen to know the previously used iv size, then use that one
    instead of '0' which uses the transfer chunks' size as iv size...
    also verify /dev/loop0 contains a properly decrypted content!
    mounting it would be a good idea, because the soft blocksize is set
    by the filesystem code -- this is needed when using '0' as
    --set-blksize arg!!!...]
# losetup -e ... /dev/loop1 /dev/blockdev
    that's for the new encrypted data, you can use the chance to change
    encryption parameters as well... i.e. another cipher or
    passphrase...
    and now for the important step: (make sure the filesystem isn't
    mounted anymore)
# dd if=/dev/loop0 of=/dev/loop1
    this will take some time... it will decrypt the data per /dev/loop0
    and encrypt it through /dev/loop1 back to /dev/blockdev
    on-the-fly... (you could use also different /dev/blockdev's if you
    don't trust this procedure...)
# losetup -d /dev/loop0
    unloop /dev/loop0...
    ...now you should have completed the conversion... /dev/loop1 should
    contain your unencrypted data... and /dev/blockdev the new encrypted
    view of it...

> The patches seem to work:  I can swap on an rc6 encrypted partition
> using the patches, and I can create an ext2 filesystem on an rc6 loopback
> file, copy some data to it, unmount, losetup -d, losetup -e, mount it
> again, and _still access the data afterwards_.  Whee!
...well, if it wasn't so, you'd have implemented some kind of data
shredder... *g*

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142