linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pascal Brisset <pascal.brisset-ml@wanadoo.fr>
To: linux-kernel@vger.kernel.org
Subject: [BUG] Data corruption with cryptoloop, 2.6.0-test1
Date: Sun, 27 Jul 2003 18:33:43 +0200	[thread overview]
Message-ID: <20030727163223.B2BD44002C7@mwinf0501.wanadoo.fr> (raw)

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 541 bytes --]

linux-2.6.0-test1, util-linux-2.12, RedHat 9, i386.

The script below demonstrates data corruption when transfering
large files (larger than physical RAM) with cryptoloop and AES.
Individual bytes are altered on 512-byte boundaries.

The problem occurs:
- when the encrypted filesystem is ext2/ext3/jf, but not msdos/vfat.
- with swap disabled
- with crypto_yield() disabled
- with cipher_null instead of AES (after patching crypto_null.c).

This looks like a race condition between flushing and loops.
Could someone confirm this ?

Pascal


[-- Attachment #2: cryptoloop-test.sh --]
[-- Type: text/plain, Size: 1189 bytes --]

#!/bin/sh

echo "Data will be destroyed. Please edit this script first."
exit 1

SIZE=256                      # Set this to more than physical RAM (MB).
FS=/dev/hda10
# FS=/tmp/cryptoloop-test.fs  # No corruption with file-backed loops.
FSTYPE=ext2
LOOP=/dev/loop10
MOUNT=/tmp/cryptoloop-test
DATA=/dev/zero
CIPHER=aes
# CIPHER=cipher_null          #  Must fix crypto_null.c first.

modprobe cryptoloop
modprobe crypto_null
modprobe aes

[ -b $FS ]  ||  dd if=/dev/zero of=$FS bs=1M count=$((SIZE+10))
echo 0123456789ABCDEF  |  losetup -p 0 -e $CIPHER $LOOP $FS  ||  exit 1
mkfs -t $FSTYPE $LOOP  ||  exit 1
mkdir -p $MOUNT
mount -t $FSTYPE $LOOP $MOUNT  ||  exit 1

dd if=$DATA bs=1M count=$SIZE of=$MOUNT/x 
hexdump $MOUNT/x  |  head

# Result (should be all 0000):
#
# 0000000 0000 0000 0000 0000 0000 0000 0000 0000
# *
# 0010000 00e0 0000 0000 0000 0000 0000 0000 0000
# 0010010 0000 0000 0000 0000 0000 0000 0000 0000
# *
# 0010200 00e0 0000 0000 0000 0000 0000 0000 0000
# 0010210 0000 0000 0000 0000 0000 0000 0000 0000
# *
# 0010400 00e0 0000 0000 0000 0000 0000 0000 0000
# 0010410 0000 0000 0000 0000 0000 0000 0000 0000

umount $MOUNT
losetup -d $LOOP
[ -b $FS ]  ||  rm $FS


[-- Attachment #3: crypto_null.c.patch --]
[-- Type: text/plain, Size: 1436 bytes --]

diff -ru linux-2.6.0-test1.orig/crypto/crypto_null.c linux-2.6.0-test1/crypto/crypto_null.c
--- linux-2.6.0-test1.orig/crypto/crypto_null.c	2003-07-14 05:33:47.000000000 +0200
+++ linux-2.6.0-test1/crypto/crypto_null.c	2003-07-28 18:07:34.000000000 +0200
@@ -22,8 +22,9 @@
 #include <asm/scatterlist.h>
 #include <linux/crypto.h>
 
-#define NULL_KEY_SIZE		0
-#define NULL_BLOCK_SIZE		1
+#define NULL_MIN_KEY_SIZE	0
+#define NULL_MAX_KEY_SIZE	32   /* losetup always uses LO_KEY_SIZE */
+#define NULL_BLOCK_SIZE		8 /* Prevents oops in cryptoloop ? */
 #define NULL_DIGEST_SIZE	0
 
 static int null_compress(void *ctx, const u8 *src, unsigned int slen,
@@ -48,10 +49,10 @@
 { return 0; }
 
 static void null_encrypt(void *ctx, u8 *dst, const u8 *src)
-{ }
+{ memcpy(dst, src, NULL_BLOCK_SIZE); }
 
 static void null_decrypt(void *ctx, u8 *dst, const u8 *src)
-{ }
+{ memcpy(dst, src, NULL_BLOCK_SIZE); }
 
 static struct crypto_alg compress_null = {
 	.cra_name		=	"compress_null",
@@ -87,9 +88,9 @@
 	.cra_module		=	THIS_MODULE,
 	.cra_list		=	LIST_HEAD_INIT(cipher_null.cra_list),
 	.cra_u			=	{ .cipher = {
-	.cia_min_keysize	=	NULL_KEY_SIZE,
-	.cia_max_keysize	=	NULL_KEY_SIZE,
-	.cia_ivsize		=	0,
+	.cia_min_keysize	=	NULL_MIN_KEY_SIZE,
+	.cia_max_keysize	=	NULL_MAX_KEY_SIZE,
+	.cia_ivsize		=	8,  /* Prevents oops in cryptoloop ? */
 	.cia_setkey		= 	null_setkey,
 	.cia_encrypt		=	null_encrypt,
 	.cia_decrypt		=	null_decrypt } }



                 reply	other threads:[~2003-07-27 16:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030727163223.B2BD44002C7@mwinf0501.wanadoo.fr \
    --to=pascal.brisset-ml@wanadoo.fr \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).