Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for single encrypted partition? #2

Open
stephen304 opened this issue Oct 25, 2017 · 8 comments
Open

Support for single encrypted partition? #2

stephen304 opened this issue Oct 25, 2017 · 8 comments

Comments

@stephen304
Copy link

stephen304 commented Oct 25, 2017

Is it possible to use this with a single partition containing both root and boot, with an esp partition?

The GRUB wiki here claims that, when using an encrypted boot:

/boot is not required to be kept in a separate partition; it may also stay under the system's root / directory tree.

I would like to use this configuration (512M EFI and single root partition containing boot) to simplify the encryption setup. That way I don't have to worry about mounting boot, but I still don't want to manually handle all the key signing by myself.

It would be great of this supported having the boot partition with the root partition. Thoughts?

@stephen304
Copy link
Author

stephen304 commented Oct 26, 2017

I can't sleep so I'm gonna add details of my partial success using this. I set up Arch with a 512 ESP and a large single partition for LUKS:

nvme0n1p1 -> /boot/efi
nvme0n1p2 -> /

I obviously skipped cryptboot mount / unmount, and had no issues running cryptboot-efikeys create / enroll. The only part that doesn't work out of the box is updating/signing. This I accomplished by manually running:

grub-mkconfig -o "/boot/grub/grub.cfg"
grub-install --target=x86_64-efi --boot-directory="/boot" --efi-directory="/boot/efi" --bootloader-id="GRUB"
cryptboot-efikeys sign "/boot/efi/EFI/grub/grubx64.efi"

It doesn't look too far off from supporting /boot and root in a single partition, since my set up requires only a subset of the existing code. It just needs to not check crypttab on line 61 and not check for boot mount on 68, unless I've overlooked something. Maybe these can be disabled by a flag or a check of some sort.

@maximbaz
Copy link

Thank you very much for posting the workaround!

@stephen304
Copy link
Author

You're welcome!

I was pondering this again and I almost got confused about how my thing works now. So for more information for other people (and potentially future me if I forget this again), my /boot dir is on my root partition, but my 512M ESP is mounted in /boot/efi when the system is running.

I use this command to verify that the signature is fine after updating grub:

sudo cryptboot-efikeys verify "/boot/efi/EFI/grub/grubx64.efi"

With secureboot enabled and bios password on, the BIOS verifies the grubx64.efi on the unencrypted ESP partition, then continues to decrypt the root, where the ESP partition is remounted.

@maximbaz
Copy link

That's exactly the setup I made for myself yesterday 🙂

I can't wrap my head around one question, could you perhaps give me a hint? To update /boot/efi/EFI/grub/grubx64.efi you have to run grub-install, but what or who is supposed to run grub-install - me? Upgrading grub package in Arch doesn't seem to automatically trigger this command (I tried to downgrade grub, didn't sign anything, rebooted and was able to boot)... so do we need to run grub-install manually?

@stephen304
Copy link
Author

I'm not sure actually, I run it myself (those 3 commands in my second comment), but I haven't really bothered to check.

In theory, updating grub should place in a new grubx64.efi which would need to be signed. I don't have a grub update pending so it's not easy for me to test now, but a good way to tell would be to compare md5 of the file before and after grub update, as well as checking cryptboot-verify before and after.

I'm pretty sure running grub-install wipes out the signature.

@maximbaz
Copy link

maximbaz commented Dec 28, 2017

That's my point, it looks like upgrading grub does not place a new grubx64.efi by itself, and thus we are stuck with the old grubx64.efi (that doesn't require re-signing) even after we upgrade grub package - that is, until we manually run grub-install which does wipe out the signature.

I guess that's why this tool provides cryptboot upgrade which basically just runs pacman -Syu and then regardless of what has been upgraded calls cryptboot update-grub, which in turn runs grub-install - this of course happens way too often than needed.

cryptboot/cryptboot

Lines 111 to 130 in 16117e1

update-grub)
echo "Regenerating GRUB config file..."
grub-mkconfig -o "$BOOT_DIR/grub/grub.cfg"
echo "Reinstalling GRUB to EFI System partition..."
grub-install --target=x86_64-efi --boot-directory="$BOOT_DIR" --efi-directory="$EFI_DIR" --bootloader-id="$EFI_ID_GRUB"
echo "Signing GRUB with UEFI Secure Boot keys..."
"$EFIKEYS_BIN" sign "$EFI_DIR/$EFI_PATH_GRUB"
sync
;;
upgrade)
$0 mount
echo "Upgrading packages..."
$PKG_UPGRADE_CMD
if [[ "$BOOT_LOADER" = "GRUB" ]]; then
$0 update-grub
fi
$0 umount
;;

In summary, I think by default we never have to re-sign grubx64.efi, because by default it is never upgraded.

@stephen304
Copy link
Author

Yeah I always just check to make sure it still has a valid signature to make sure I'm not going to need to whip out a recovery arch stick at some random time in the future.

@maximbaz
Copy link

All right, thanks for the answers and sorry for drifting off-topic here 🙂.

I've asked my question on Arch forums to follow up, subscribe if you are interested: https://bbs.archlinux.org/viewtopic.php?pid=1757673

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants