Phil H wrote: > The loop.ko in initrd is compiled from the standalone loopaes sources > (currently); cipher modules in extra is compiled from the combined > loop+cipher sources. [snip] > The serpent module compiled from the standalone cipher sources inserted > and appeared to work, while tainting the kernel. But this serpent module > from the combined sources won't insert at all. [snip] > I replaced the loop.ko module in initrd.gz compiled from the standalone > loop-aes sources with that compiled from the combined sources and rebuilt > the iso. [snip] > Ciphers insert now, no kernel tainting, no errors of any kind in dmesg! Ok. When loop_serpent.ko was built using ciphers source package, it didn't find matching loop.ko module it could pull symbol version info from. So symbol version info in loop_serpent.ko was set to unknown. This module loaded to kernel, but since it had unknown symbol version info in some of its symbols, module loading code said "dunno if this works, all bets off", and tainted kernel. When loop_serpent.ko was built using new Makefile (EXTRA_CIPHERS=y), build system knew exactly what versions of symbols it needed from loop.ko module, and these known versions were written to loop_serpent.ko module. When you attempted to load loop_serpent.ko to kernel, module loading code detected that there was clear symbol version mismatch, and said "sod off, this doesn't belong here at all", and refused to load the module. When initrd.gz has a loop.ko built using new Makefile (EXTRA_CIPHERS=y), symbol versions match exactly, no errors, no kernel tainting occours. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
