Hi Jari, hi all,
this one has been on my personal wishlist for a long time. I'd like
to describe my motivation and ask you what you think of the idea.
One of the larger complexities in the current packaging of loop-AES
for Debian stems from wanting to build the modules with correct
symbol versions for 2.6 kernels that use CONFIG_MODVERSIONS=y.
The only way I've found was to combine loop-AES and ciphers in one
package and to build them together with a shared MODVERDIR. This
actually worked quite well until sometime around 2.6.16 or 2.6.17.
With more recent kernels, something broke and caused the cipher
modules to again log a warning about unversioned symbol from loop-AES
and consequently taint the kernel.
loop_twofish: no version for "md5_transform_CPUbyteorder_C" found:
kernel tainted.
To work around this specific problem, I'm applying somewhat of a
hack that copies loop_*.c into the loop-AES directy and uses a
small custom 2.6 kbuild Makefile to do the build. I'm attaching
the Makefile I've built which should behave just like the actual
loop-AES Makefile for recent 2.6 kernels.
This approach has been pretty reliable over the last few kernel
revisions, but has the obvious disadvantage of not using the real
uptream Makefile and needing to be maintained separately.
I think the approach of building loop-AES and ciphers together
could be applied in the kbuild Makefile that is generated by the
main loop-AES Makefile and would make symbol versions of shared
symbols work correctly.
Original upstream tarball
-------------------------
This point may be specific to the way Debian packages are
built, which I'll briefly outline below, but it could be that this
is also a factor for other distribution build systems.
Usually, a Debian package comprises of the verbatim original
tarball (.orig.tar.gz) and a Debian-specific patch (.diff.gz) that
gets applied to it. It is generally recommended that Debian
packages use the unchanged upstream tarball so that changes are
limited to and visible in the Debian patch, and so that users
of the package can verify that the .orig.tar.gz really matches
the upstream tarball and is not backdoored, etc.
(The ability to verify the tarball is modulo compression, since
Debian infrastructure is currently limited to gzip and doesn't allow
use of bzip2. Users can still uncompress both upstream.tar.bz2 and
.orig.tar.gz and compare the resulting uncompressed tarball).
Since I've started to combine loop-AES and ciphers in one package,
retaining the original tarball was no longer possible. Instead, I've
tried different approaches that all turned out less than optimal:
a) Include loop-AES.tar.bz2{,.sign} and ciphers.tar.bz2{,.sign}
unchanged in the .orig.tar.gz; Then unpack them at buildtime,
account for version number in the directory names and layer some
kind of patch system on top of it so that any required changes to
the upstream code can be applied.
Downsides: Changes appear as diff-of-diff in the Debian
.diff.gz; Much complexity at build-time.
b) Unpack loop-AES.tar.bz2 and ciphers.tar.bz2 and create a
new .orig.tar.gz with those unpacked sources. This allows
direct changes to the code using the Debian .diff.gz, but
no longer allows users to directly verify that the upstream
sources have not been modified by me.
Neither of those approaches is really statisfying. If loop-AES
and ciphers were combined in loop-AES.tar.bz2, we could take the
unchanged tarball, unbzip2, gzip, and use the result as base for the
package. This would make changes clearly visible in Debian .diff.gz
and allow users to easily verify the uncompressed tarball.
Proposal
--------
I think both points could be helped by having loop-AES and
ciphers be one software package in one tarball. It would make it
easier for users of ciphers to build and install the modules, and
last but not least would make my life as distribution package
maintainer a bit easier. :-)
Downsides: Uncompressed tarball grows by ~90k. Users who don't
need/want ciphers still get them and, if the cipher modules were
installed by default, an additional ~45k of disk space used.
What do you think?
I'm more than happy to help with this change, be it by doing
research, testing or by submitting patches.
cheers,
Max
obj-m := loop.o loop_twofish.o loop_serpent.o loop_blowfish.o
loop-y := patched-loop.o glue.o
# Use optimized assembler implementation if target is x86 processor
ifeq ($(CONFIG_X86),y)
ifeq ($(CONFIG_X86_64),y)
# amd64
loop-y += aes-amd64.o md5-amd64.o
EXTRA_CFLAGS += -DAMD64_ASM
else
# x86
loop-y += aes-x86.o md5-x86.o
EXTRA_CFLAGS += -DX86_ASM
endif
else
loop-y += aes.o md5.o
CFLAGS_aes.o := -DDATA_ALWAYS_ALIGNED=1
endif
ifeq ($(KEYSCRUB),y)
EXTRA_CFLAGS += -DCONFIG_BLK_DEV_LOOP_KEYSCRUB=1
endif
ifeq ($(PADLOCK),y)
EXTRA_CFLAGS += -DCONFIG_BLK_DEV_LOOP_PADLOCK=1
endif
