Herbert Valerio Riedel wrote: > just to let you know, what the crypto patch code status is in at the > moment; You forgot to mention the "sleeping in the make_request_fn()" bug, which is a real NO-NO, and can cause a panic(). > On Tue, 10 Jul 2001, Dale Amon wrote: > > * kernel bloat. This is probably a non-issue. Linus > > will at some point go for hooks into the kernel > > for encryption support. The API for that will perhaps > > be influenced by kerneli but that will not be the > > final word. I do suspect it will have great influence > > because everyone is using the new util-linux which > > supports the new api for loopback encryption types. > > In that sense we are already main stream. > > (The util-linux support is mainstream debian now) > btw, I don't see any major kernel bloat; > the actual implementation does dynamic allocation of cipher modules, > and uses strings for identification; instead of having to use some magic > number IDs... (see also the mknod problem and devfs; which can be regarded > as kernel bloat as well... actually the whole kernel is bloat... why do we > use at all a virtual machine abstraction layer instead of coding directly > without any underlying OS?!? ;-) Crypto-api is the bloat as it is just an unnecessary layer slowing things down. If someone is unable to do string to magic number conversion in userspace, it is no excuse to do that in kernel. > > I'm pretty sure I remember a kernel discussion on some of > > the issues and there is a desire to have one single crypto > > API that is available for all purposes, loopback fs or other. > > > While loopAES is very nice for now, and perhaps some of the code > > will find its' way into the kernel, I don't see that as the > > likely way things will go for 2.6.x. I'm very sure that a > > loopback module will not contain its' own crypto. It will share > > it with other tools and applications. We are not going to see > > 5 loadable modules providing different services each with its' > > own implimentation of AES. Loop-AES kernel patch version (kernel-2.4.diff) exports three fully re-entrant functions for everyone to use: void aes_set_key(aes_context *, const unsigned char [], const int, const int); void aes_encrypt(const aes_context *,const unsigned char [],unsigned char []); void aes_decrypt(const aes_context *,const unsigned char [],unsigned char []); > another subsystem; virtual memory encryption, can make use of the > cryptoapi as well... There is no need to modify VM. Device backed loop-AES-v1.4d can handle swapping just fine. > we really need to unify all those crypto related kernel space projects; > otherwise linus surely won't let them go into the kernel (at least I > expect this, judging from the past ;-) There are places where crypto can't go, but Linux must go. I don't like it, but I can understand keeping crypto out of mainline kernel. Regards, Jari Ruusu <jari.ruusu@xxxxxxxxxx> Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
