[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    Roundup of 2.4 kerneli problems and call for developers (was: Re: max
From:       Marc Mutz <Marc () Mutz ! com>
Date:       2001-02-21 18:16:01
[Download RAW message or body]

pacman wrote:
> 
<snip>
> kernel config ist attached.
<snip> 
(You don't need to base64-encode a plain text file, just send it as
7but, and additionally, you could use
grep -Ev '^$|^#' /usr/src/linux/.config | sed s/^CONFIG_//
to remove the noise. Thanks)

If this problem occurs only with partitions >2G, I think this is a 32bit
issue. I don't know if this is a kernli issue or an incompatibility
between loop-5 and kerneli.

This mail is titled "... and call for developers". I think we could very
well use some additional ones...

So I'd like to point all of you that have problems with kerneli in 2.4
(or want to become a developer) to the following:

2.4 (and 2.2.18.4pre) patches use a new architecture both in module
loading and the loopback crypto driver. The "stable" version on 2.2. is
still 2.2.18.3; on 2.4.x such a thing does not exist, yet. It is hard to
develop something when the underlying arthitecture is deeply buggy and
the bug is not considered serious enough to be fixed before 2.4.0 :-(

Known problems (w/ fixes if avaliable)

a. loop.c is buggy in all 2.4.x kernels, resulting in a complete system
hang when accessing the loop device for some time/amount of data. Lens
Axboe has a loop-5 patch[1] but AFAIK this reworks the loop device
heavily. Don't expect a loop-5 patched kernel to work with the kerneli
patch that was written for 2.4.x vanilla. There is no kerneli that I
know of that is taylored to loop-5.

b. previous versions of losetup/mount had the ciphername-number
translation table hardcoded into them. That meant re-compiling them
whenever a cipher changed or was added. BAD. This was changed in a way
that makes losetup/mount independent of the installed drivers: The IOCTL
to setup the loop_gen driver was changed to take a ciphername instead of
an (internal) ciphernumber as parameter. The name->number conversion is
now done in the kernel via find_cipher_by_name(). Also, there were
changes in the module loading code in cryptoapi.c. That has two
implications:

b1. Early versions of the 2.4.x patches were unable to handle the
old-style IOCTL. You'd get "LOOP_SET_STATUS: Invalid argument" messages
if that was the case. 2.4.0.3 has this fixed.

b2. (I guess) The module loading code has still a bug, causing losetup
to segfault. This comes up when you demand-load blowfish (and other
ciphers) the first time. Workaround: Load the modules before you run
losetup.

The problem is that I am not running 2.4.x. I do run 2.2.18.4pre1, but I
am not into the new design to debug the "losetup segfaults" error. If
there is someone that is a better C/Unix programmer than I am (which is
easy to accomplish), I'd appreciate if he or she took a look at the
code. It is not much code and quite independent of everything else in
the kernel except the loop device. I worked my way into the (old)
sources in a few hour's time so there should likely be people out there
that can do this in less than an hour.

This project certainly lacks developers, because Gisle has just finished
his/her (heck, I don't even know Gisle's sex!?) master thesis (or so I
understand) and is likely gone job-hunting, /me is just starting his
diploma thesis (finally :-) and Astor seems to be wrapped up in work,
too.

If you can help, you're welcome...

Marc

[1] ftp.kernel.org/pub/linux/kernel/people/axboe/<kernelversion>/loop-5*
-- 
Marc Mutz <Marc@Mutz.com>     http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

[prev in list] [next in list] [prev in thread] [next in thread]