On Sat, 12 Feb 2000, Alan Cox wrote:
> > > passed index as IV. It is already part of the disk format. The only
> > > way to change it is to add new vectors to loop_func_table and keep
> > > the absolute offset for the old files. Then new encryption modules
> > > could use the changed format, but old ones would still work with the
> > > known limitations.
> >
> > Oh, please. Decrypt the thing with old kernel and reencrypt it with new one.
> > Problem solved. Or use the trivial userland program to switch the format -
> > FIBMAP is alive and well, so you can get the disk block number from userland.
>
> There are people with gigabyte encrypted file systems, there are people who want
> to be able to switch back and forth between old and new kernels. You broke it
> plain and simple. You made a gratuitious on disk format change that isnt
> needed.
Sigh... Alan, I'm sorry, but could you try to use /dev/loop on 2.3.43? And
watch the show. The most trivial test being: dd if=/dev/zero of=foo count=40
losetup /dev/loop0 foo; yes|dd count=20 >/dev/loop0; losetup -d /dev/loop0;
Now check foo. It was broken in many interesting ways.
Again, comment from original variant:
* WARNING/FIXME:
* - The block number as IV passing to low level transfer functions is broken:
* it passes the underlying device's block number instead of the
* offset. This makes it change for a given block when the file is
* moved/restored/copied and also doesn't work over NFS.
Putting this breakage back is not a problem, indeed. But as for gratitious...
See above for reasons. BTW, for loopback over devices encoding remains the
same as it used to be. I'm not saying that it's ideal variant (see the comment
in patch), but at least the thing fixes very real breakage for files with holes
and for _any_ write access to /dev/loop. Changing it so that it would use
->bmap() result for IV is, indeed, possible, but I'ld rather see that done in
encryption modules. Notice that they are getting enough information to call
->bmap() and get the on-disk block number. And IMO it's the right place for
such thing - generic code should _not_ try to do it, since it will be outright
impossible for NFS _and_ since the reverse transformation is impossible.
The bottom line: encryption driver can trivially compensate for the change.
So if it's a problem with on-disk format - fine, let's keep the transformation
in the format-handling code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:23 EST