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.
-
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:24 EST