Closed piec closed 8 years ago
I haven't done any work on the autogeneration of config and I don't know if it supports the crypto options, even without my enhancement patches.
I haven't done anything to the autogeneration code so it definately does not support the detached headers, keyfiles or any other options that I added.
I personally think that using crypto and specifically detaching headers/lkeys or using alternative ciphers or plain mode is "advanced" and would require the end-user to hand-craft their grub.cfg. That's how I do it and I think my handcrafted grub.cfg is much simpler and easier to understand than the autogenerated stuff anyway. But that's my opinion only and the Grub folks probably see it differently.
I agree with you about autogeneration of grub.cfg, but I'm not talking about that or I didn't really understand what you wrote. I'm using grub-install here not grub-mkconfig.
I'm talking about using GRUB_ENABLE_CRYPTODISK=y
so that /boot/grub is also in an encrypted partion. Before showing the grub menu, grub asks for the passphrase to unlock the luks volume.
I don't really know the inner working of that option but my current setup is just a single luks partition with /boot included in it. As documented in this article
I'd rather use a detached header. But I don't know how to :)
Ah, sorry I misunderstood you. As far as I understand it, GRUB_ENABLE_CRYPTODISK
is a setting made in /etc/default/grub
that is used by grub_mkconfig
to autogenerate grub.cfg
. You don't need that if you aren't autogenerating.
The grub-install
puts Grub on the bootable medium so that it can be booted. If you're doing grub.cfg
by hand then you need to manually put your config onto /grub/grub.cfg
on the boot medium.
If you want to use an encrypted boot that means that Grub needs to open the filesystem that contains the initial ramfs which, in turn, needs to open the filesystem that contains the kernel image (which it has to do even if it the initramfs and the kernel are on the same filesystem).
The way that I implemented it is with an entire encrypted disk containing LVM so that "/boot", where the kernel is located, is just a subdirectory of the root filesystem which is an LVM volume and, therefore, encrypted.
The initramfs is loaded from the USB stick and it contains the required configuration to unlock the root filesystem to make the kernel accessible. How that works depends on whether you're using an init or systemd based initramfs. This is described on the Arch wiki and in the threads I referred to earlier.
Note that none of the above require Grub to decrypt if the initramfs is stored unencrypted on the USB stick. You can, of course, locate it on an encrypted partition on the USB stick and then use Grub's cryptomount -H... hd0,2
to access that, or locate it on the same encrypted LVM as the kernel, in which case you'd use something like
insmod luks
cryptomount -H /header -k /key hd1
linux (lvm/volgroup-volume)/boot/vmlinuz-linux \
root=/dev/mapper/volgroup-volume rw
initrd (lvm/volgroup-volume)/boot/initramfs-linux.img
Here, the USB would be hd0 and the first hard drive would be hd1.
The only thing that can't be encrypted is the initial grub.cfg
that is loaded by Grub. You can "chain load" a second configuration that is on an encrypted filesystem if you want.
What I do is have Grub open an encrypted filesystem on the USB stick and load a second grub.cfg
from there that uses LUKS headers and keys stored in that encrypted partition to open the encrypted LVM on the hard disc to access the initramfs and kernel there.
I think there are lots of ways to implement an encrypted boot and it really comes down to what youre needs are, and they may be different to mine.
Does that make any sense at all?
@johnlane do you happen to have a blog post about your pendrive setup that loads the LUKS headers from the pendrive?
@attila-lendvai have you seen this page ? I also wrote a more in-depth article for Linux Format. It doesn't cover the encryption part but does explain how to set up the usb stick.
@johnlane thank you, i'll take a look!
(linuxformat is currently down)
Hi again John
I suppose this is not supported yet by grub-install I did:
And I got
(where xxx is the luks uuid)
I would have to tell grub-install where to find the header anyway. Am I missing something ? Thanks