Re: Full Disk Encryption with cgd (well, almost)

[Alan Barrett <apb%cequrux.com@localhost>]

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
consumption too.

> The approach I am taking is as follows:
> - /dev/wd0a is a small bootable partition with:
>  * boot,
>  * boot.cfg,
>  * a GENERIC kernel,
>  * a ramdisk with a kernel module,
>  * cgd.conf and the relevant encryption key
>    (cgd0 /dev/wd0e)
> - /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 
device.

> 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
>  stuff

I did not need to do anything like that.  I have this in the list.extra
file for the ramdisk:

PROG    sbin/cgdconfig
LIBS    -lcrypto

> - 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.

> Less important:
> - 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)