On 19/12/14 10:09, Diagon wrote: > > Date: Fri, 19 Dec 2014 09:37:12 +0000 > > From: John Lane <[email protected]> > > To: [email protected] > > > On 19/12/14 08:04, Andrei Borzenkov wrote: > > > ? Thu, 18 Dec 2014 23:28:08 -0800 Diagon <[email protected]> ?????: > > > >> ---- On Thu, 18 Dec 2014 22:15:32 -0800 Andrei > Borzenkov<[email protected]> wrote ---- > > >> > ? Thu, 18 Dec 2014 16:52:46 -0800 Jordan Uggla > <[email protected]> ?????: > > >>>>> 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
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
