Re: initramfs loopaes

Sebastian Faulborn schreef:
> > > There are problems with "early user space" a.k. initramfs - it causes
> > > kernel panics. I was just busy setting this up, when I read that. Can 
> > you explain a bit
> > more about your kernel version, loop-aes version and specific kernel oops?

> I am using the following setup:
> - current HLFS (SVN-20060510)
> - kernel 2.6.14.6
> - all PAX/GRSec options enabled, except EMUTRAMP, privileged io
> - current LOOP-AES (V3.1d) with current ciphers extension (see 
> http://loop-aes.sourceforge.net)
> - raid1 (software md raid) -> use mdadm to set it up
> - gnupg
> - lvm2
>
> loop-aes with cipher AES crashes (it causes a kernel oops which you can

> Its much easier to just have one encrypted partition and use lvm2 to create 
> as many partitions as you need (with the option to resize a partition as 
> you need it) on
> top of it.

> Initramfs: The kernel panics when ever I use a kernel with the frandom 
> patch. Without
> the patch (but with grsec patch) there are tons of nasty error messages 
> when initramfs
> comes up (paging fault etc.), but the system comes up(!). However, since 
> frandom is
> a central part of HLFS (the arc4random patch for glibc depends on it), I 
> was not
> willing to skip frandom. Also initrd is a lot easier to use since you 
> already have
> a completly sane system when it comes up while initramfs seems to cause 
> problems
> since not everything is yet initialized in the kernel. There also seem to 
> be problems
> if initramfs becomes too big (my initrd is ~45MB in size when it is 
> unpacked since
> it contains gnupg, lvm2 etc.).

> BTW: Which grsec patch are you using for kernel 2.6.16.15? The official 
> patches
> still only exist for 2.6.14.6.
>
> Hope this helps! Please ask if you have problems.
>
> Sebastian Faulborn
> Homepage: http://www.secure-slinux.org

Yes, this helps :-)
As far as I can predict, vaguely, I think this is going to work for me,
because I am neither using RAID, nor using encrypted root(yet). I
*think* your initramfs problems are mainly about them. I am also not
using the frandom patch, because I have a hardware based random
generator; hrandom.
( I am now wondering whether I am missing anything, due to your comment:
(the arc4random patch for glibc depends on it) )

O well, I am just going to walk the plank to see what's lurking in the
deep :-)
This is going to be a tricky road with lots of testing, but that's okay
because I am not using this in any kind of production environment, yet.
HLFS is mostly a hobby for me.
Therefore I took the gamble and opted for a newer kernel, which was
required by HAL. I applied the normal 2.6.14.6 patches and sofar they
seem to work just as before. I haven't done any extensive testing
though, because I don't have testcases beyond the HLFS-book.

There is a newer patch in the pipeline, but it's unofficial: (dated June  4)
http://www.grsecurity.net/~spender/grsecurity-2.1.9-2.6.16.19-200606041421.patch
(I haven't used this one, I already took a risk with the newer kernel
source)

So I am going to take three steps:
1 initrd   encrypted swap
2 initramfs   encrypted swap
3 initramfs   encrypted swap&root

I am using one of those Via multimedia boards with addon security
hardware. The cipher created by Joan Daemen and Vincent Rijmen is
hardware accelerated, but no others, therefore I don't have the luxury
of switching to serpent, nor do I feel like using it; the Via cpu itself
isn't very fast.
I'll just have to chat with loop-aes creator Jarin Ruusu when I get the
kernel oops in my log file.

But not for the coming month, I am going for a three week seminar in The
States, woohoo :-)

Thanks, and I'll get back to you

Warren

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/