[SOLVED] full disk encryption uefi motherboard queston about /boot

haVok1701 · 2013-05-09 23:26:37

I a little confused got a new pc and I'll be installing in the uefi manner with lvm on luks and with the efi system partition having the kernel and initramfs copied over will that completely serve as my boot partition or do i still need an unencrypted /boot?

Last edited by haVok1701 (2013-05-09 23:53:38)

haVok1701 · 2013-05-09 23:52:23

ok I was over thinking this, efi system partiton is mounted at /boot/efi so duh yes I will have a seperate unencrypted /boot

WonderWoofy · 2013-05-10 01:04:54

You could just use the ESP as /boot. I had an encrypted system for a bit, and this is what I did. Though I have always mounted my ESP on /boot...

I guess it just depends on how you like to organze your system and what bootloader or boot manager you use. If, for example, you use gummiboot, the kernel and initramfs will have to be on the ESP, so there is no point in separating out the ESP from /boot. The only time this makes sense is if you are using something that can actually read the /boot partition (that is ext{2,3,4}, btrfs, etc.). I think that all the UEFI bootloaders can do this, and of the boot managers rEFInd can do this as well.

Last edited by WonderWoofy (2013-05-10 01:05:14)

srs5694 · 2013-05-10 03:35:29

re: Using an ESP that's separate from /boot:

WonderWoofy wrote:

The only time this makes sense is if you are using something that can actually read the /boot partition (that is ext{2,3,4}, btrfs, etc.). I think that all the UEFI bootloaders can do this, and of the boot managers rEFInd can do this as well.

The capabilities of boot managers and boot loaders are more complex than this:

The ELILO boot loader relies on the EFI to read the kernel and initrd file. Normally, this means that they must reside on a FAT partition (usually the ESP), although if some other tool has loaded an EFI filesystem driver, that filesystem can be used. The ELILO documentation refers to a capability to read kernels from something other than ELILO's partition, but I've never figured out how to get that to work. (The documentation doesn't say how to specify another partition -- a frustrating omission.)
Fedora's patched GRUB Legacy boot loader has built-in drivers that enable it to read ext2/3/4fs, ReiserFS, XFS, JFS, and I believe Btrfs, as well as several non-Linux filesystems (I think these include FAT, HFS+, and ISO-9660, but I'm not positive of that). It can't handle LVM, RAID, or encrypted setups, though.
The GRUB 2 boot loader can read everything that GRUB 2 can, plus LVM and RAID setups. I'm not sure about encryption, offhand.
The kernel's EFI stub loader relies on the firmware to read its initrd file, and so can read whatever the firmware can read -- just FAT by default, but this can be extended via an EFI driver.
The gummiboot boot manager relies on the EFI to read the kernel, and gummiboot provides no means to launch drivers. It's also restricted to reading files from the partition from which it was launched. Thus, as a practical matter, gummiboot works only if the kernel is on the ESP, or at least on a FAT partition, or HFS+ on a Mac. (It's possible to rig up a system in which rEFIt or rEFInd launches gummiboot from a non-FAT partition, but that's overly-complex, IMHO.)
The rEFInd boot manager relies on the EFI to read the kernel. Unlike most other tools, though, rEFInd can launch EFI drivers prior to scanning filesystems. It can also launch kernels from any partition that the EFI can read. rEFInd ships with drivers for ext2/3fs, ext4fs, ReiserFS, HFS+, and ISO-9660, but not for XFS, JFS, or Btrfs. If you find or write another EFI filesystem driver, rEFInd could launch it. AFAIK, there are no EFI drivers for LVM, RAID, or Linux encryption systems. Thus, as a practical matter, rEFInd can launch kernels stored on the most popular Linux filesystems, but not from LVM, RAID, or encrypted partitions.
The rEFIt boot manager (rEFInd's predecessor) is not ideal for launching Linux kernels directly, although it can be done if you jump through enough hoops. It comes with ext2/3fs and ReiserFS drivers, but not the other drivers that rEFInd supports. (You could use rEFInd's drivers with rEFIt, though.) It can launch a boot loader from any partition that the EFI can read.

I realize that's a lot of detail to take in, and it makes it impossible to draw broad conclusions about filesystem support of boot loaders vs. boot managers. Instead, though, I'd say that they can be ordered, from most flexible to least flexible, as: GRUB 2, GRUB Legacy, rEFInd, rEFIt, ELILO, and finally gummiboot.

Strike0 · 2013-05-10 19:42:04

Great summary of capabilities. Since the OP is asking about booting an lvm on luks, let me add that neither Grub2 or Fedora's version can boot that directly too. Off-topic: There is an approach to secure grub, but you require a TPM for it. For EFI the upcoming alternative is the secureboot (i.e. not encryptedboot as in filesystem capability either) whirls

The nature of the OPs system setup does not require much flexibility by the boot loader. Rather one wants to keep the (required) unencrypted boot small. Currently I would give a +1 to WonderWoofy's approach.

srs5694 · 2013-05-10 22:48:43

Strike0 wrote:

For EFI the upcoming alternative is the secureboot (i.e. not encryptedboot as in filesystem capability either) whirls

Your link is to a description of the Linux Foundation's PreBootloader. This is easier than the competing shim for users to set up on distributions (like Arch) that lack official Secure Boot support; but in the long run shim is more flexible. FWIW, I've got two pages on the topic of Secure Boot; one for EFI boot loaders generally and the other for rEFInd specifically. Secure Boot doesn't really have anything to do with filesystem encryption, but if a computer supports it, Secure Boot could enhance security slightly.

The nature of the OPs system setup does not require much flexibility by the boot loader. Rather one wants to keep the (required) unencrypted boot small. Currently I would give a +1 to WonderWoofy's approach.

I agree that if you can plan ahead of time and are using Arch, mounting the ESP at /boot simplifies matters slightly and enables you to use the broadest range of boot loaders/managers; but some distributions don't like FAT on /boot, so this is awkward at best if you're dual-booting with, say, OpenSUSE. My second-choice approach is a separate FAT /boot partition, but again, FAT on /boot can be a problem in some configurations. (You could use a FAT /boot for Arch and another /boot partition with something else for another distribution, though.) My third-choice approach is either a separate /boot partition with ext2/3/4fs or ReiserFS; or no separate /boot partition with one of those filesystems on an unencrypted, non-LVM, and non-RAID root (/) filesystem. The last half of that final option is obviously a non-starter if disk encryption is required.

Strike0 · 2013-05-12 20:56:20

Thank you, I enjoyed reading your two pages. The second one I was unaware of, it is just as educative as the first. You come to the same conclusion for shim as MJG himself in the link I posted. It will be interesting to see how the planned merged boot loader he writes about will look like.
When I commented on the setup above, it was purely on the usecase the OP set out briefly, i.e. the OP did not mention multiboot. When I setup an encrypted multiboot I usually used your third-choice approach. It seemed easier (and less errorprone for existing installations) to give the new distro a dedicated ext2/3/4 boot partition for installation purposes, boot from it once to update and then switch back to the original /boot and adjust the boot-loader/manager to automate updates to the multi-/boot partition (or letting that idle around).

srs5694 wrote:

Secure Boot doesn't really have anything to do with filesystem encryption, but if a computer supports it, Secure Boot could enhance security slightly.

There is pros and cons (take away the rage) about Secureboot. It addresses specific aspects of (boot-chain) security only. Yet for those I consider the _technical_ enhancement considerable really, not slight. This is because other attempts (prior to an activated secureboot) to close those gaps are proprietary/non-standard or at the very least even more cumbersome to setup/maintain even for advanced users. Plus it has been a long, long way .. better the best of it now. That said I hope the non-Secureboot capable hardware in this household does it a bit longer ;-)

Arch Linux

#1 2013-05-09 23:26:37

[SOLVED] full disk encryption uefi motherboard queston about /boot

#2 2013-05-09 23:52:23

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

#3 2013-05-10 01:04:54

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

#4 2013-05-10 03:35:29

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

#5 2013-05-10 19:42:04

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

#6 2013-05-10 22:48:43

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

#7 2013-05-12 20:56:20

Re: [SOLVED] full disk encryption uefi motherboard queston about /boot

Board footer