Re: initramfs loopaes Warren Wilder Wed Jun 28 07:37:11 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 bitmore about your kernel version, loop-aes version and specific kernel oops?
I am using the following setup: - current HLFS (SVN-20060510) - kernel 126.96.36.199 - 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) ontop 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 sinceit contains gnupg, lvm2 etc.).
BTW: Which grsec patch are you using for kernel 188.8.131.52? The official patchesstill only exist for 184.108.40.206. 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 220.127.116.11 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-18.104.22.168-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 _________________________________________________________________Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/