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

[Diagon]

 > 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'd like to learn how to use the keyfile as you do.  Is that described on your 
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?

/D