sfaulborn at web.de
Tue Jun 27 04:27:34 PDT 2006
> > There are problems with "early user space" a.k. initramfs - it causes
> > kernel panics. I am back to initrd.
> > Loop-AES crashes with AES cipher (though not with serpent - which is
> > more secure anyway). I
> > assume this is because I have PAX/kexec enabled in the kernel.
> > Sebastian Faulborn
> > Homepage: http://www.secure-slinux.org
>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 setting this up because I want to make use of suspend2 with an
>encrypted swapfile, and perhaps encrypted root as well (some day or never).
>( it's all pretty much explained here:
> http://wiki.suspend2.net/EncryptedSwapAndRoot )
>I wouldn't like to hear that this is a simple no go on a HLFS system,
>but I would like to know before spending more time on this :-) .
>Currently I am using 22.214.171.124 with loop-aes 3.1d, if that matters at all.
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
Basically install gnupg as described in HLFS, install loop-aes and ciphers as described
at http://loop-aes.sourceforge.net. With all PAX settings enabled except for EMUTRAMP,
loop-aes with cipher AES crashes (it causes a kernel oops which you can see in the
syslog - after that mount/loop-device hangs). Older versions used to work fine with HLFS.
I now use the serpent cipher instead (which is part of the cipher extension). It has
stronger encryption than aes (I use serpent192 in multikey-v3 mode) and is approved
by the NSA to be secure enough for government use.
My setup is as follows:
- unencrypted boot partition on raid1
- encrypted partition (rest of harddisk) on raid 1 -> loop-aes with serpent192 cipher
- lvm2 on top of encrypted partition -> /, /var, /tmp, /data, swap on top of lvm2
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.
This setup has been in use for 1,5 years with hlfs with no problems at all. The current
HLFS has been in use on a production server since about 1 month with this setup and
there are no problems either (it currently serves 350GB/month to the internet).
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.).
The loop-aes people say that with encrypted root you cannot free the memory used
by the initrd - this is not true. You cannot unmount /dev - however you can move
it with the rebind option of the mount command. After that unmount the ramdisk
used by initrd (and flush the buffers). /dev only consumes a few kB - so thats
no problem! Note you can (and should) unmount all the devices on /dev/* and
that you can remove all nodes in there(!).
Note: if you encrypt your data/root partition, always use encrypted swap. Its
also always a good idea to keep data on raid1. My experience with software raid
is better than with hardware raid (often very sensitive hardware which fails
a lot more often than normal ide/scsi controllers). You can expect no delays
because of software raid1 and no noticeable delays because of loop-aes
(however the loop-device will consume up to 30% of processing time when
you are using your harddisk 100% - in average there should be no slow down
of your software though since your harddisk will only be used a fraction of
BTW: Which grsec patch are you using for kernel 188.8.131.52? The official patches
still only exist for 184.108.40.206.
Hope this helps! Please ask if you have problems.
More information about the hlfs-dev