Re: GRUB & crypto? (& generally, more info on undocumented modules?)

[John Lane]

On 19/12/14 10:09, Diagon wrote:

 > Date: Fri, 19 Dec 2014 09:37:12 +0000 
 > From: John Lane <address@hidden> 
 > To: address@hidden 
 
 > On 19/12/14 08:04, Andrei Borzenkov wrote: 
 > > ? Thu, 18 Dec 2014 23:28:08 -0800 Diagon <address@hidden> ?????: 

 > >> ---- On Thu, 18 Dec 2014 22:15:32 -0800 Andrei Borzenkov<address@hidden> wrote ----  
 > >>  > ? Thu, 18 Dec 2014 16:52:46 -0800 Jordan Uggla <address@hidden> ?????:  

 >>>>> Grub can read files from LUKS and GELI volumes, but only FreeBSD's  
 >>>>> kernel currently has a protocol for passing credentials from grub to  
 >>>>> the kernel, so if you're using GNU/Linux and you use grub's LUKS  
 >>>>> support to read your kernel from your LUKS encrypted root, you will  
 >>>>> need to enter your password twice at boot: Once for grub, and again  
 >>>>> for linux.  
  
 >>>> There are patches to support use of keyfile; this could improve  
 >>>> situation for by allowing shared keyfile between GRUB and Linux and  
 >>>> unattended decryption. 

[...]

 >> http://grub.johnlane.ie/ 

[...] 

 > I thought I'd mention my specific use-case for using crypto routines in 
 > Grub. 
 >  
 > I have some devices that are configured to boot from a USB drive that I 
 > keep attached to my keys and, usually, in my pocket :) 
 >  
 > These devices contain encrypted disks that have no boot sectors and 
 > cannot boot themselves. The unlocked disks are LVM and contain a root 
 > logical volume. This has a "/boot" directory containing the kernel and 
 > initramfs images. 
 >  
 > Booting Grub from the USB uses "cryptomount" to unlock the encrypted 
 > disk and this allows Grub's LVM to activate the root volume. Grub then 
 > uses the images in "/boot" on that volume to boot the system. There is 
 > no need to maintain copies of the boot images on the USB drive. 
 >  
 > I use a keyfile to avoid the duplicate passphrase entry issue. The 
 > keyfile is on the USB stick. It's also inside the initramfs so that the 
 > booting kernel can also unlock the disk. It's safe because the initramfs 
 > is on an encrypted volume. 
 >  
 > By having "/boot" on the root volume, it's easy to perform system 
 > updates in-situ without having to worry about copying images onto the 
 > USB stick (which may not be phyisically present when such an update is 
 > performed). 
 >  
 > I also use detached LUKS headers and keep them separately too. 

John - this is exactly what I want to do.  Thank you for jumping in!  What I have been doing so far is as described here:

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1223622

(You'll see patches there.)

I see you've been doing this a while. I couldn't find anything on it so ended up doing it myself.
My stuff is here: http://grub.johnlane.ie and fully functional. I've mentioned it on grub-devel and
hopefully it might get taken upstream. If not, then just check out my github repo.

I'd like to learn how to use the keyfile as you do.  Is that described on your site?

You can do this:

insmod luks
cryptomount -H (hd0,1)/header -k (hd0,1)/keyfile hd1,1

There are several other examples on my site.

One thing confuses me.  You say:

 > By having "/boot" on the root volume, it's easy to perform system 
 > updates in-situ without having to worry about copying images onto the 
 > USB stick (which may not be phyisically present when such an update is 
 > performed). 

The USB does not hold the kernel/initramfs, but it does hold the /boot/grub partition, with core.img, modules and grub.cfg.  The OS does occasionally need to update that stuff, in which case the USB would need to be present, no?

I don't see Grub as a dependency of the OS, so the two can be decoupled. Unless I am missing something, there is no reason why an OS update would mandate a bootloader update. If I want to update Grub on the USB I just mount the relevant partition and do:

$ mount /dev/sdj1 /mnt
$ grub-install --no-floppy --boot-directory=/mnt /dev/sdj

Obviously the Grub needs to have the required Grub Modules in it (e.g. my extended "cryptodisk" module). I hand-craft my grub.cfg because what I am doing is specific to me and I can keep the Grub.cfg lean and easy to understand. I don't (yet) use the autogenerate stuff but I may look into it. My goal was to understand how it all worked and get it going at a basic level first.

Whenever I update my OS, it installs new kernel and initramfs to /boot, totally oblivious to how those files get used.

/D