On Fri, Oct 13, 2000 at 10:15:21PM +0000, Marc Mutz wrote:
> Andi Kleen wrote:
> >
> > On Fri, Oct 13, 2000 at 05:04:08PM +0000, Marc Mutz wrote:
> > > Andi Kleen wrote:
> > > >
> > > <snip>
> > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > > from disk absolute to relative). When you change it now (before 2.4.0)
> > > > it is relatively painless. I think the change is a good idea.
> > > <snip>
> > >
> > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to
> > > use relative block numbers as IV's. Both the FAQ in Documentation/crypto
> > > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'.
> >
> > That is not a standard kernel option. I'm not talking about any unofficial
> > patchkits like the i* patches, just about what the standard loop device does.
> > An encryption module can be backwards compatible itself by mapping the blocks
> > itself, but without changes it will have an incompatible on disk format.
> >
>
> This thread was about encryption. And it was about IV's. The only
> encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'.
> None is just that: a no-op. And xor does not use an IV. So the only
> ciphers that could possibly have been adressed by this patch are the
> ones in the kerneli patch. So the on-disk format did _not_ change
And any other filter modules which use the open loadable block
converter interface in the loop device. That kerneli exists as a patch is
IMHO just an historical accident, near all of it can be done fine without
ever touching any linux source at all. Please take a small peek out of
your small world ;)
BTW, kerneli would also not handle the case of switching block sizes anyways,
with relative IVs or not, because it does not restart its CFB chain inside
the device blocks every 512 byte blocks with a new IV. When you switch
from a bigger block size to a smaller you would need backwards peeking to
earlier blocks (and know the block size anyways). Similar problem for
going to bigger blocks. Ingo's change makes it a bit less painless, but
still not trivial to handle.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:26 EST