initramfs loopaes

Warren Wilder wipwap19 at hotmail.com
Wed Jun 28 04:33:16 PDT 2006


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/




More information about the hlfs-dev mailing list