On Sun, Feb 13, 2000 at 01:04:15AM +0100, Alexander Viro wrote:
>
>
>
> On Sun, 13 Feb 2000, Andi Kleen wrote:
>
> > > 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.
> >
> > Unfortunately they can not. One design problem of loopback crypto is
> > that you cannot store any additional information. The only way to
> > check if the user entered the right password is to see if ext2 can mount
> > the file system. There is really no way to detect old and new format.
>
> HUH? You don't need the additional information. You need a different version
> of module that would work with 2.3/2.4 (and I hope that you didn't use
> loopback right before the change - it's severely fscked up as of 2.3.43).
Lots of people use loopback in 2.2.x, where it works fine.
> This version of module should take the page number/offset it got, take the
> lo->lo_dentry->d_inode->i_mapping, find mapping->bmap(mapping, block). That
> will be the on-disk block. What additional information are you talking about?
> Kernel version? lo->transfer() gets lo, it gets page->index, it gets offset
> within the page. What else do you need to calculate the physical block position
> (== old IV)?
Nothing.
The additional information is whether the disk image uses the absolute
or the relative IVs.
The bad part of the change is to make the relative IV the default, it needs
to be an optional feature for new filter modules that know what they are
doing (or that they don't need to worry about backwards compatibility)
The way to do that is to add new function vectors to loop_func_table.
-Andi
-- This is like TV. I don't like TV.- 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