linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] cryptoloop
@ 2003-07-02 18:44 Andries.Brouwer
  2003-07-02 19:02 ` Andrew Morton
                   ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 18:44 UTC (permalink / raw)
  To: Andries.Brouwer, akpm; +Cc: linux-kernel, torvalds

akpm:

> You'll note that loop.c goes from (page/offset/len) to (addr/len),
> and this transfer function then immediately goes from (addr,len)
> to (page/offset/len). That's rather silly ..

Changing that would kill all existing modules that use the loop device.

Maybe nobody cares. Then we can do so in a subsequent patch.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-04 13:21 Andries.Brouwer
  2003-07-04 13:28 ` Christoph Hellwig
  0 siblings, 1 reply; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-04 13:21 UTC (permalink / raw)
  To: Andries.Brouwer, hch; +Cc: akpm, akpm, jari.ruusu, linux-kernel, torvalds

>> Oh, Christoph - can't you just be a tiny bit more civil.

> Maybe I could.

Good!


Andries


BTW - So far, Clemens and Jari and I have been cooperating and
discussing every step. Most of your statements seem unfounded to me.

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-04 11:08 Andries.Brouwer
  2003-07-04 12:13 ` Christoph Hellwig
  0 siblings, 1 reply; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-04 11:08 UTC (permalink / raw)
  To: hch, jari.ruusu; +Cc: Andries.Brouwer, akpm, akpm, linux-kernel, torvalds

hch to jari:

> So get your code merged. Moaning about breaking out of tree code beeing
> broken by changes when an in-kernel alternative eists doesn't help.
>
> Either try to help improving what's in the tree or shut up.


Oh, Christoph - can't you just be a tiny bit more civil.

Here is an ungoing process of merging crypto/loop code.
You are perfectly aware of that - you complained about
every single stage - the rfc patch at the start was
too large, the whitespace in the next patch was distributed
incorrectly, also the third part had terrible bugs - I forget,
maybe there was a superfluous #include.

Now that you are very aware of this ongoing effort
of merging the loop stuff that so far lived as separate
patches outside the kernel tree, how can you say
"get your code merged"? That is precisely what we are
doing right now. Slowly. Step by step.


Andrew on the other hand apparently didnt know, and commented
on something that can be improved. Excellent. For this patch #3
that comment was not relevant, but no doubt we must try and
follow his good advice in some subsequent patch. Preferably
without breaking existing user space.


Try to follow Andrew's example - nice, friendly, constructive.
It is possible to be a good coder without being abusive.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-03 16:25 Andries.Brouwer
  2003-07-03 16:31 ` Christoph Hellwig
  0 siblings, 1 reply; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-03 16:25 UTC (permalink / raw)
  To: Andries.Brouwer, hch; +Cc: linux-kernel, torvalds

hch:

> Some nitpicking:

Thanks. In case Linus applied the patch this is unimportant.
In case he didnt I'll probably resubmit when 2.5.75 comes out
and apply your polishing.

> +     if (info->lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
>
> this special-casing sounds like a bad idea.

True. But it is only in the compatibility code.
Once you rip that out the special casing disappears automatically.
It describes current reality.

> imho we should rip out the whole concept of transfer functions

They are used much more frequently than cryptoapi is.
People tell me jari-loop is much faster at present.
If this is true, your move would not be very popular.

Anyway, I am not doing a redesign. Just a cleanup.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-02 22:57 Andries.Brouwer
  0 siblings, 0 replies; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 22:57 UTC (permalink / raw)
  To: Andries.Brouwer, akpm; +Cc: linux-kernel, torvalds

    From Andrew.Morton@digeo.com  Wed Jul  2 23:36:40 2003

    > Now suppose one wants a large dev_t. Some people do.

    <thumps table> 2.6 will support a large dev_t.

    We need to make this happen.

Very well.

    > Then several steps are needed. One of these steps
    > is the addition of the mknod64 system call.
    > That is a nice small isolated step - part of the necessary
    > user space interface. It can be done independently of any
    > other steps. It was submitted, but is not in the present
    > kernel. Why not? I do not recall anybody pointing out problems.

    This precisely illustrates my point.

    mknod64() and several other dev_t patches (ext2 and ext3 support,
    especially) have stalled in -mm for months.  The reason why I have not
    moved ahead with them is that I am waiting to see the rest of the work.

That is what they call a deadlock.
You asked a few times what parts could be submitted and I answered.

    Because it could be that Al has different ideas, or that someone else gets
    down and completes the work and wants to do it differently.  I simply do
    not know.

Neither do I. I just wait and see.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-02 22:27 Andries.Brouwer
  0 siblings, 0 replies; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 22:27 UTC (permalink / raw)
  To: Andries.Brouwer, greg; +Cc: akpm, linux-kernel, torvalds

[on large dev_t]:

> I was wondering what had happened here with this.
> What is left to do to finish full support?

It is not quite clear what "full support" means.
(And not clear what "left" means. Roughly speaking I did
everything, but today part of that would have to be redone.)


Suppose that one regards stat/mknod as communication
userspace <-> filesystem.
Then one wants stat() to be able to return 64-bit dev_t,
and mknod() to be able to bring 64 bits to the filesystem.

Several filesystems have room for only 16 or 32 bits, while some
have room for 128 bits. So details will be filesystem-dependent.

I seem to recall that among the submitted patches was one
that added ext2 support for 64-bit dev_t.
For some other filesystems things were settled. E.g. for NFS.
And there was mknod64.


That is one part. But there is more than stat/mknod.
Every system call and ioctl that uses a dev_t parameter or
a dev_t field in some parameter struct must be looked at.
Do we want to deprecate the thing that has not been used
the past nine years? Or do we need a foo64 version?
Maybe I have patches for all cases.
Don't recall whether I finished the audit. Anyhow,
I would have to do it again - last time was several months ago,
new calls may have been added since.


That is the interface with user space.
Strange enough people are not satisfied with nice large numbers
in special device nodes on the filesystem. They would like to
see something meaningful happen when they open() such a node.

This means that the kernel must be able to find a device driver
or so given a large number. That can be done using a hash table
lookup. But what one really wants is that a device driver can
register an interval of device numbers. Then hash lookup does
not work so well, and one needs a tree lookup. Maybe Al did this
wrong at first in the block device code. I have not checked whether
that has improved recently, but I saw that he did work on the
character device part. Must read that in case this series of
patches is restarted.


So, coming back to your question: what is needed?
Maybe I already had all needed fragments, and earlier my
uncertainty was mostly about the possible existence of
some obscure ioctl on some obscure architecture (not m68, Geert)
that I might have overlooked.

I think the -mm kernels have had (still have?) most of these
large dev_t patches, and basically these did not cause problems.

So what is needed today is looking at the present kernel.
Redoing the syscall and ioctl audit.
Getting the patches into the tree.
Getting glibc to update <sys/sysmacros.h> and stat/mknod/ustat.


And all of this is only the use of the numbers.
Good support for large numbers of disks is something entirely
different. I recall that there were scaling problems, e.g.
with sysfs.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-02 21:00 Andries.Brouwer
  2003-07-02 21:06 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 21:00 UTC (permalink / raw)
  To: Andries.Brouwer, akpm; +Cc: linux-kernel, torvalds

    From Andrew.Morton@digeo.com  Wed Jul  2 22:03:49 2003

    > (Usually I plan a track and submit individual steps.
    > When they get applied I continue.
    > If not, there is no need to waste time on the rest.)

    As someone who is on the receiving end of this process I must say that it
    is not comfortable.

    It really helps to be able to see the whole thing laid out all at the same
    time.  So we can see that it works, so that we can see that the end result
    is the right one, etc.

    Whereas receiving a long drawn out trickle of patches is quite confusing. 
    One doesn't know where it is leading, nor where it will end, nor when to
    get down and actually start testing it, etc.  Nor whether this ongoing
    churn is stomping on someone else's development effort.

    And there is the risk that you get halfway through and then suddenly "no
    way, we don't want to do that".  Then what?  Argue?  Revert?

No, the point of such a series is that each patch does something
clearly defined, is an improvement even when the author dies the
next day so that all further work is lost.

You should never accept a patch that makes things worse and is only
justified by a future one.

    So for everyone except the guy who's writing the code it is best to have
    all the work in place and reviewable at the same time.

No. Some changes are too large for that.

    For the author, yes, there is a risk that more code than necessary will be
    tossed away.  We can minimise that by discussing things beforehand, getting
    understanding and agreement from the relevant people on the intended
    direction.  I think we have done that for cryptoloop.  We still have not
    really done it for 64-bit dev_t.

Yes, now that you remind me, that is also an interesting topic.
About discussing beforehand - search the archives and you'll see
immense amounts of discussion on large dev_t.
You'll always find me willing to discuss details.

Now suppose one wants a large dev_t. Some people do.
Then several steps are needed. One of these steps
is the addition of the mknod64 system call.
That is a nice small isolated step - part of the necessary
user space interface. It can be done independently of any
other steps. It was submitted, but is not in the present
kernel. Why not? I do not recall anybody pointing out problems.

I think some of these large dev_t steps were somewhat urgent, because
they were prerequisites for glibc changes. But they didnt happen.
Linus took a bit from me, and you submitted a few steps from me,
and then nothing. OK.

Dave compared the patch submission process to TCP/IP.
I agree, and go into exponential backoff. Try again after two weeks,
three months, a year and a half.
But if you want we can restart that particular series of patches.
Or discuss, if there are things to discuss.

Andries

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [PATCH] cryptoloop
@ 2003-07-02 19:42 Andries.Brouwer
  2003-07-02 19:58 ` Andrew Morton
  0 siblings, 1 reply; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 19:42 UTC (permalink / raw)
  To: Andries.Brouwer, akpm; +Cc: linux-kernel, torvalds

* akpm> Where are the first and second patches btw?  Merged?  Is a fourth
* akpm> anticipated?)

Yes, merged.

(Usually I plan a track and submit individual steps.
When they get applied I continue.
If not, there is not need to waste time on the rest.)

Here a series of about half a dozen steps was announced.


* akpm> Splitting these changes into two almost doubles the testing effort,

One should always go in many small steps.
Each step so that it is clear what happens.
Preferably with different steps separated by a kernel release,
so that if things break, people can tell at what kernel version.


* akpm> Could we pleeeze have a little cryptoloop.txt which just gives
* akpm> the basics on where to obtain the tools and how to get the thing
* akpm> up and running?  It's a right pain having to go scrabbling
* akpm> all over the internet working out how to set stuff up
* akpm> if you just want to do a bit of testing every few months.

Please read the help message in the config menu.
Then read the text accompanying my patch.
When still needed, read losetup(8).

Andries



[Let me say the same things in different words. You want to test.
I think you are too early, since I have not released util-linux 2.12,
and will wait until this, or a similar, patch has been applied.
You can test that no old things are broken by using mount (-o loop)
or losetup. If you are really very eager I can prepare a tar file
for you and put it on some ftp site.]


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [PATCH] cryptoloop
@ 2003-07-02 15:21 Andries.Brouwer
  2003-07-02 17:16 ` Andrew Morton
  2003-07-03 15:44 ` Christoph Hellwig
  0 siblings, 2 replies; 38+ messages in thread
From: Andries.Brouwer @ 2003-07-02 15:21 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

This is part 3 in the loop series.

It adds a module cryptoloop, with source file drivers/block/cryptoloop.c
and config option BLK_DEV_CRYPTOLOOP. It is the missing link between
the kernel crypto subdirectory and the loop device.
This means that one no longer needs kernel patches to use encryption
via the loop device. This goes together with mount and losetup from
util-linux 2.12 which will be released as soon as this goes in.

The configuration menu texts were shortened a bit. On the one hand
because the URLs were outdated. On the other hand, because such a
discussion is more appropriate for Documentation/loop.txt than for
a configuration menu.

There was an unfortunate clash between software that used lo_name
for the (possibly truncated) filename of the loop device -- of course
for informational purposes only --, and the software that used it
for the name of the crypto algorithm.  I separated both roles.

The cryptoloop code is basically that from hvr@gnu.org and
clemens@endorphin.org.

The unused char key_reserved[48] was removed.

Andries

diff -u --recursive --new-file -X /linux/dontdiff a/drivers/block/Kconfig b/drivers/block/Kconfig
--- a/drivers/block/Kconfig	Thu May 22 13:16:20 2003
+++ b/drivers/block/Kconfig	Wed Jul  2 16:45:41 2003
@@ -237,29 +237,20 @@
 	  root file system inside a DOS FAT file using this loop device
 	  driver.
 
-	  The loop device driver can also be used to "hide" a file system in a
-	  disk partition, floppy, or regular file, either using encryption
+	  To use the loop device, you need the losetup utility, found in the
+	  util-linux package, see
+	  <ftp://ftp.kernel.org/pub/linux/utils/util-linux/>.
+
+	  The loop device driver can also be used to "hide" a file system in
+	  a disk partition, floppy, or regular file, either using encryption
 	  (scrambling the data) or steganography (hiding the data in the low
 	  bits of, say, a sound file). This is also safe if the file resides
-	  on a remote file server. If you want to do this, you will first have
-	  to acquire and install a kernel patch from
-	  <ftp://ftp.kerneli.org/pub/kerneli/>, and then you need to
-	  say Y to this option.
-
-	  Note that alternative ways to use encrypted file systems are
-	  provided by the cfs package, which can be gotten from
-	  <ftp://ftp.kerneli.org/pub/kerneli/net-source/>, and the newer tcfs
-	  package, available at <http://tcfs.dia.unisa.it/>. You do not need
-	  to say Y here if you want to use one of these. However, using cfs
-	  requires saying Y to "NFS file system support" below while using
-	  tcfs requires applying a kernel patch. An alternative steganography
-	  solution is provided by StegFS, also available from
-	  <ftp://ftp.kerneli.org/pub/kerneli/net-source/>.
-
-	  To use the loop device, you need the losetup utility and a recent
-	  version of the mount program, both contained in the util-linux
-	  package. The location and current version number of util-linux is
-	  contained in the file <file:Documentation/Changes>.
+	  on a remote file server.
+
+	  There are several ways of doing this. Some of these require kernel
+	  patches. The vanilla kernel offers the cryptoloop option. If you
+	  want to use that, say Y to both LOOP and CRYPTOLOOP, and make sure
+	  you have a recent (version 2.12 or later) version of util-linux.
 
 	  Note that this loop device has nothing to do with the loopback
 	  device used for network connections from the machine to itself.
@@ -271,6 +262,14 @@
 
 	  Most users will answer N here.
 
+config BLK_DEV_CRYPTOLOOP
+	tristate "Cryptoloop Support"
+	depends on BLK_DEV_LOOP
+	---help---
+	  Say Y here if you want to be able to use the ciphers that are 
+	  provided by the CryptoAPI as loop transformation. This might be
+	  used as hard disk encryption.
+
 config BLK_DEV_NBD
 	tristate "Network block device support"
 	depends on NET
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/block/Makefile b/drivers/block/Makefile
--- a/drivers/block/Makefile	Thu May 22 13:16:20 2003
+++ b/drivers/block/Makefile	Wed Jul  2 17:38:52 2003
@@ -30,3 +30,4 @@
 
 obj-$(CONFIG_BLK_DEV_UMEM)	+= umem.o
 obj-$(CONFIG_BLK_DEV_NBD)	+= nbd.o
+obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) += cryptoloop.o
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/block/cryptoloop.c b/drivers/block/cryptoloop.c
--- a/drivers/block/cryptoloop.c	Thu Jan  1 01:00:00 1970
+++ b/drivers/block/cryptoloop.c	Wed Jul  2 18:17:51 2003
@@ -0,0 +1,191 @@
+/*
+   Linux loop encryption enabling module
+
+   Copyright (C)  2002 Herbert Valerio Riedel <hvr@gnu.org>
+   Copyright (C)  2003 Fruhwirth Clemens <clemens@endorphin.org>
+
+   This module is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This module is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this module; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/module.h>
+#include <linux/version.h>
+
+#include <linux/init.h>
+#include <linux/config.h>
+#include <linux/string.h>
+#include <linux/crypto.h>
+#include <linux/blkdev.h>
+#include <linux/loop.h>
+#include <linux/blk.h>
+#include <asm/semaphore.h>
+#include <asm/uaccess.h>
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("loop blockdevice transferfunction adaptor / CryptoAPI");
+MODULE_AUTHOR("Herbert Valerio Riedel <hvr@gnu.org>");
+
+#define LOOP_IV_SECTOR_BITS 9
+#define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS)
+
+static int
+cryptoloop_init(struct loop_device *lo, const struct loop_info64 *info)
+{
+	int err = -EINVAL;
+	char cms[LO_NAME_SIZE];			/* cipher-mode string */
+	char *cipher;
+	char *mode;
+	char *cmsp = cms;			/* c-m string pointer */
+	struct crypto_tfm *tfm = NULL;
+
+	/* encryption breaks for non sector aligned offsets */
+
+	if (info->lo_offset % LOOP_IV_SECTOR_SIZE)
+		goto out;
+
+	strncpy(cms, info->lo_crypt_name, LO_NAME_SIZE);
+	cms[LO_NAME_SIZE - 1] = 0;
+	cipher = strsep(&cmsp, "-");
+	mode = strsep(&cmsp, "-");
+
+	if (mode == NULL || strcmp(mode, "cbc") == 0)
+		tfm = crypto_alloc_tfm(cipher, CRYPTO_TFM_MODE_CBC);
+	else if (strcmp(mode, "ecb") == 0)
+		tfm = crypto_alloc_tfm(cipher, CRYPTO_TFM_MODE_ECB);
+	if (tfm == NULL)
+		return -EINVAL;
+
+	err = tfm->crt_u.cipher.cit_setkey(tfm, info->lo_encrypt_key,
+					   info->lo_encrypt_key_size);
+	
+	if (err != 0)
+		goto out_free_tfm;
+
+	lo->key_data = tfm;
+	return 0;
+
+ out_free_tfm:
+	crypto_free_tfm(tfm);
+
+ out:
+	return err;
+}
+
+typedef int (*encdec_t)(struct crypto_tfm *tfm,
+			struct scatterlist *sg_out,
+			struct scatterlist *sg_in,
+			unsigned int nsg, u8 *iv);
+
+static int
+cryptoloop_transfer(struct loop_device *lo, int cmd, char *raw_buf,
+		     char *loop_buf, int size, sector_t IV)
+{
+	struct crypto_tfm *tfm = (struct crypto_tfm *) lo->key_data;
+	struct scatterlist sg_out = { 0, };
+	struct scatterlist sg_in = { 0, };
+
+	encdec_t encdecfunc;
+	char const *in;
+	char *out;
+
+	if (cmd == READ) {
+		in = raw_buf;
+		out = loop_buf;
+		encdecfunc = tfm->crt_u.cipher.cit_decrypt_iv;
+	} else {
+		in = loop_buf;
+		out = raw_buf;
+		encdecfunc = tfm->crt_u.cipher.cit_encrypt_iv;
+	}
+
+	while (size > 0) {
+		const int sz = min(size, LOOP_IV_SECTOR_SIZE);
+		u32 iv[4] = { 0, };
+		iv[0] = cpu_to_le32(IV & 0xffffffff);
+
+		sg_in.page = virt_to_page(in);
+		sg_in.offset = (unsigned long)in & ~PAGE_MASK;
+		sg_in.length = sz;
+
+		sg_out.page = virt_to_page(out);
+		sg_out.offset = (unsigned long)out & ~PAGE_MASK;
+		sg_out.length = sz;
+
+		encdecfunc(tfm, &sg_out, &sg_in, sz, (u8 *)iv);
+
+		IV++;
+		size -= sz;
+		in += sz;
+		out += sz;
+	}
+
+	return 0;
+}
+
+
+static int
+cryptoloop_ioctl(struct loop_device *lo, int cmd, unsigned long arg)
+{
+	return -EINVAL;
+}
+
+static int
+cryptoloop_release(struct loop_device *lo)
+{
+	struct crypto_tfm *tfm = (struct crypto_tfm *) lo->key_data;
+	if (tfm != NULL) {
+		crypto_free_tfm(tfm);
+		lo->key_data = NULL;
+		return 0;
+	}
+	printk(KERN_ERR "cryptoloop_release(): tfm == NULL?\n");
+	return -EINVAL;
+}
+
+static struct loop_func_table cryptoloop_funcs = {
+	number:		LO_CRYPT_CRYPTOAPI,
+	init:		cryptoloop_init,
+	ioctl:		cryptoloop_ioctl,
+	transfer:	cryptoloop_transfer,
+	release:	cryptoloop_release,
+	owner:		THIS_MODULE
+};
+
+static int __init
+init_cryptoloop(void)
+{
+	int rc;
+
+	if ((rc = loop_register_transfer(&cryptoloop_funcs))) {
+		printk(KERN_ERR
+		       "cryptoloop: register loop transfer function failed\n");
+		return rc;
+	}
+
+	printk(KERN_INFO "cryptoloop: loaded\n");
+	return 0;
+}
+
+static void __exit
+cleanup_cryptoloop(void)
+{
+	if (loop_unregister_transfer(LO_CRYPT_CRYPTOAPI))
+		printk(KERN_ERR
+			"cryptoloop: unregistering transfer funcs failed\n");
+
+	printk(KERN_INFO "cryptoloop: unloaded\n");
+}
+
+module_init(init_cryptoloop);
+module_exit(cleanup_cryptoloop);
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/block/loop.c b/drivers/block/loop.c
--- a/drivers/block/loop.c	Wed Jul  2 16:22:55 2003
+++ b/drivers/block/loop.c	Wed Jul  2 16:45:41 2003
@@ -840,7 +840,8 @@
 	lo->lo_flags = 0;
 	lo->lo_queue.queuedata = NULL;
 	memset(lo->lo_encrypt_key, 0, LO_KEY_SIZE);
-	memset(lo->lo_name, 0, LO_NAME_SIZE);
+	memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
+	memset(lo->lo_file_name, 0, LO_NAME_SIZE);
 	invalidate_bdev(bdev, 0);
 	set_capacity(disks[lo->lo_number], 0);
 	filp->f_dentry->d_inode->i_mapping->gfp_mask = gfp;
@@ -892,7 +893,10 @@
 			return -EFBIG;
 	}
 
-	strlcpy(lo->lo_name, info->lo_name, LO_NAME_SIZE);
+	memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE);
+	memcpy(lo->lo_crypt_name, info->lo_crypt_name, LO_NAME_SIZE);
+	lo->lo_file_name[LO_NAME_SIZE-1] = 0;
+	lo->lo_crypt_name[LO_NAME_SIZE-1] = 0;
 
 	if (!xfer)
 		xfer = &none_funcs;
@@ -931,7 +935,8 @@
 	info->lo_offset = lo->lo_offset;
 	info->lo_sizelimit = lo->lo_sizelimit;
 	info->lo_flags = lo->lo_flags;
-	strlcpy(info->lo_name, lo->lo_name, LO_NAME_SIZE);
+	memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
+	memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
 	info->lo_encrypt_type =
 		lo->lo_encryption ? lo->lo_encryption->number : 0;
 	if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
@@ -957,7 +962,10 @@
 	info64->lo_flags = info->lo_flags;
 	info64->lo_init[0] = info->lo_init[0];
 	info64->lo_init[1] = info->lo_init[1];
-	memcpy(info64->lo_name, info->lo_name, LO_NAME_SIZE);
+	if (info->lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
+		memcpy(info64->lo_crypt_name, info->lo_name, LO_NAME_SIZE);
+	else
+		memcpy(info64->lo_file_name, info->lo_name, LO_NAME_SIZE);
 	memcpy(info64->lo_encrypt_key, info->lo_encrypt_key, LO_KEY_SIZE);
 }
 
@@ -975,8 +983,11 @@
 	info->lo_flags = info64->lo_flags;
 	info->lo_init[0] = info64->lo_init[0];
 	info->lo_init[1] = info64->lo_init[1];
-	memcpy(info->lo_name, info64->lo_name, LO_NAME_SIZE);
-	memcpy(info->lo_encrypt_key,info64->lo_encrypt_key,LO_KEY_SIZE);
+	if (info->lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
+		memcpy(info->lo_name, info64->lo_crypt_name, LO_NAME_SIZE);
+	else
+		memcpy(info->lo_name, info64->lo_file_name, LO_NAME_SIZE);
+	memcpy(info->lo_encrypt_key, info64->lo_encrypt_key, LO_KEY_SIZE);
 
 	/* error in case values were truncated */
 	if (info->lo_device != info64->lo_device ||
diff -u --recursive --new-file -X /linux/dontdiff a/include/linux/loop.h b/include/linux/loop.h
--- a/include/linux/loop.h	Wed Jul  2 16:23:00 2003
+++ b/include/linux/loop.h	Wed Jul  2 16:45:41 2003
@@ -36,7 +36,8 @@
 	int		(*transfer)(struct loop_device *, int cmd,
 				    char *raw_buf, char *loop_buf, int size,
 				    sector_t real_block);
-	char		lo_name[LO_NAME_SIZE];
+	char		lo_file_name[LO_NAME_SIZE];
+	char		lo_crypt_name[LO_NAME_SIZE];
 	char		lo_encrypt_key[LO_KEY_SIZE];
 	int		lo_encrypt_key_size;
 	struct loop_func_table *lo_encryption;
@@ -49,7 +50,6 @@
 	struct block_device *lo_device;
 	unsigned	lo_blocksize;
 	void		*key_data; 
-	char		key_reserved[48]; /* for use by the filter modules */
 
 	int		old_gfp_mask;
 
@@ -102,7 +102,8 @@
 	__u32		   lo_encrypt_type;
 	__u32		   lo_encrypt_key_size;		/* ioctl w/o */
 	__u32		   lo_flags;			/* ioctl r/o */
-	__u8		   lo_name[LO_NAME_SIZE];
+	__u8		   lo_file_name[LO_NAME_SIZE];
+	__u8		   lo_crypt_name[LO_NAME_SIZE];
 	__u8		   lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
 	__u64		   lo_init[2];
 };

^ permalink raw reply	[flat|nested] 38+ messages in thread
end of thread, other threads:[~2003-07-08 12:30 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-02 18:44 [PATCH] cryptoloop Andries.Brouwer
2003-07-02 19:02 ` Andrew Morton
2003-07-02 19:16   ` Linus Torvalds
2003-07-02 19:20     ` Andrew Morton
2003-07-02 19:31       ` Linus Torvalds
2003-07-03 11:21 ` Jari Ruusu
2003-07-03 15:20   ` Andrew Morton
2003-07-03 17:29     ` Jari Ruusu
2003-07-03 17:38       ` Chris Friesen
2003-07-04  7:43         ` Jari Ruusu
2003-07-04  8:44           ` Andrew Morton
2003-07-04  9:41           ` Christoph Hellwig
2003-07-05  8:41             ` Jari Ruusu
2003-07-05  8:58               ` Andrew Morton
2003-07-05  9:00                 ` Andre Hedrick
2003-07-05  9:10               ` Andre Hedrick
2003-07-05 17:16               ` James Morris
2003-07-05 17:20               ` Linus Torvalds
2003-07-08 12:43               ` Christoph Hellwig
2003-07-04  9:39       ` Christoph Hellwig
2003-07-03 16:20 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2003-07-04 13:21 Andries.Brouwer
2003-07-04 13:28 ` Christoph Hellwig
2003-07-04 11:08 Andries.Brouwer
2003-07-04 12:13 ` Christoph Hellwig
2003-07-03 16:25 Andries.Brouwer
2003-07-03 16:31 ` Christoph Hellwig
2003-07-02 22:57 Andries.Brouwer
2003-07-02 22:27 Andries.Brouwer
2003-07-02 21:00 Andries.Brouwer
2003-07-02 21:06 ` Greg KH
2003-07-02 21:31 ` Andrew Morton
2003-07-03 16:23 ` Christoph Hellwig
2003-07-02 19:42 Andries.Brouwer
2003-07-02 19:58 ` Andrew Morton
2003-07-02 15:21 Andries.Brouwer
2003-07-02 17:16 ` Andrew Morton
2003-07-03 15:44 ` Christoph Hellwig

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).