[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Full Disk Encryption with cgd (well, almost)
On Thu, 21 Mar 2013, Pierre Pronchery wrote:
I have just managed to prototype a way to achieve (almost) full disk
encryption with cgd. I have tried to implement this while altering the
least amount of existing code and infrastructure that I could.
Thank you. I should probably try to make my setup suitable for public
The approach I am taking is as follows:
- /dev/wd0a is a small bootable partition with:
* a GENERIC kernel,
* a ramdisk with a kernel module,
* cgd.conf and the relevant encryption key
- /dev/wd0e is the cgd partition
- the ramdisk (ramdisk-cgdroot.fs) was generated with the patch
attached, a lot like for sysinst but with cgdconfig instead
- the kernel module is generated from this ramdisk
- boot.cgd boots the GENERIC kernel with the ramdisk enabled
(menu=Boot:load /cgdroot.kmod;boot /netbsd.gz)
- a minimal /etc/rc within the ramdisk
* mounts wd0a on /etc/cgd,
* asks for the passphrase (with "cgdconfig -C"),
* mounts the encrypted volume read-only (on "/altroot"),
* and tells init (via "sysctl -w init.root=/altroot") to chroot
before going on
- the system starts normally.
All that sounds fine. My own setup is similar, but I don't
use cgd.conf (I store the necessary parameters in a separate
partition), and I parse dmesg to figure out the boot device, so
it works with booting from an internal disk (wd0) and an external
USB disk (sd0). We should probably add a sysctl for the booted
A few additional remarks:
- init really needs SMALLPROG disabled to handle the "init.root" sysctl
(took me a while to figure out...)
I added SMALLPROG.init=no and the necessary changes to make that work,
so there's no need to globally disable SMALLPROG.
- I had to move dmesg and ftp out of the common ramdisk code for amd64
because they did not build anymore with SMALLPROG disabled (WRT ftp it
is related to SSL support)
- likewise, cgdconfig needs -lcrypto so I had to duplicate the libhack
I did not need to do anything like that. I have this in the list.extra
file for the ramdisk:
- I guess cgdroot.kmod is not built automatically with these changes,
I'll welcome suggestions there
- I am not sure about the "right" way to generate cgdroot.kmod; I'm
afraid, as it is, that it will try to build before miniroot.kmod is
available (still have to test this)
- I guess I want the one in OBJDIR instead; what's the proper variable?
This part should be easy.
I believe this approach to be generic enough to be worth being available
in the source tree. It would certainly make more sense if sysinst would
support creating such setups out of the box - but IMHO this is a first
step in this direction. Some of you have achieved similar setups already
in different ways - let me know if if a consensus can be reached here.
This approach seem fine as a first step. It can be refined later.
- I guess "/altroot" was not exactly meant for this, but I read it as
"alternate root" here and I find it adequate (?)
- the key is stored on the hard drive in this scenario, but that's not
worse than the current official cgd howto
- I think it wouldn't work as-is with a XEN3_DOM0 kernel (which would
require the ramdisk built in the kernel AFAICS)
All that seems fine. The final step of building the ramdisk into
the kernel instead of creating a miniroot.kmod will have to change
for some platforms.
--apb (Alan Barrett)
Main Index |
Thread Index |