On Sun, Feb 13, 2000 at 01:41:49AM -0500, Alexander Viro wrote:
>
>
>
> On Sun, 13 Feb 2000 kernel@draper.net wrote:
>
> > I considered and rejected passing relative block numbers to the transfer
> > modules for use as IV seeds. The last thing I wanted to see was
> > duplication of ciphertext on my disk drive (occurs when multiple looped
> > filesystems exist on the same drive using the same cipher and key).
> > Such duplication at minimum is "interesting" to the cryptanalysis, and
> > at worst facilitates recovery of plain text.
> >
> > Many of the Linux community consider loop.c to be broken. Astor in his
> > kerneli International Crypto Patches favors relative block, as does
> > Al Viro in this thread... and I too acknowledge that relocation of backing
> > files, in all its flavors, is desirable in some environments.
>
> Erm... Let me clarify: I think that _passing_ absolute block numbers is wrong.
> It has nothing with cryptography - it's an interface matter. Usage of
> absolute vs. relative block numbers in the encryption module is policy
> question - the module itself should decide which (if any) it wants. Passing
> relative numbers allows that, since they always make sense and getting the
> absolute number from relative is trivial. Passing absolute ones doesn't.
> That's it. Which ones you use a question of format and it should be decided
> by the module, not by the kernel.
>
> > That said, there remain the exemptionally paranoid among us who need
> > access to absolute block numbers as IV seeds.
>
> Which will remain available as long as we support LILO. IOW, until the hell
> will freeze. I'ld rather avoid using it in the core kernel (the only remaining
> place being the handling of swap and it's a mess that can and IMO should be
> fixed), but if the module explicitly wants to know absolute location of block -
> well, why not? We have an interface that gives exactly that and at least one
> holy cow requires keeping it working.
>
> So yes, it's an interface change, but I think that it's worth doing - if we
> want loopback over NFS or encryption that uses relative block numbers we have
> to break binary compatibility of _modules_ (not formats) anyway and since the
> changes required in modules are trivial I think that even broken source
> compatibility is not that much a problem in this case.
>
Al, I agree 100%... I think the benefits outway the cost of building
version tolerence into the transfer code. (I wonder how many transfer
modules exist, not many I'll wager). I am committed to changing those
which I authored.
Reed,
-
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:25 EST