Encrypted root and /boot on legacy BIOS on Ubuntu 14

Hi all,

Here's how you install Ubuntu 14 with a LUKS-encrypted / and /boot partition when using legacy BIOS:

1. Install Ubuntu. You'll want to create a 256M /boot (unencrypted), a LUKS container with LVM for /.


2. Boot the system to prove that it boots correctly.


3. Copy the contents of /boot somewhere, and note the device (say /dev/sda1 for this example).


4. cryptsetup luksFormat /dev/sda1 -c aes-xts-plain64
   DO NOT install LVM here; grub2 refuses to allow FS writes to LVM volumes, which is needed for recordfail.


5. Create an entry in /etc/crypttab for the new LUKS container. We'll assume you called the device-mapper node "boot_crypt".


6. /etc/init.d/cryptdisks-early start (prove that crypttab works)


7. mkfs.ext4 /dev/mapper/boot_crypt -L boot (or whatever filesystem you want here)


8. Edit /etc/fstab to point /boot to /dev/mapper/boot_crypt.


9. Copy the saved files from step 3 into the new /boot.


10. echo 'GRUB_ENABLE_CRYPTODISK=y' >> /etc/default/grub


11. grub-install -v (verify that grub-mkimage is called with luks/cryptodisk modules included)


12. update-grub


13. Reboot. Grub should now prompt to unlock the disk before showing the boot menu. For extra credit, set up LUKS keys for automount, since the only thing unencrypted on your HDD is grub, so in theory you could stash the key for the rootfs LUKS keys in the initramfs.

Encrypted root and /boot on regular UEFI on Ubuntu 14

Hi all,

Here's how you install Ubuntu 14 with a LUKS-encrypted / and /boot partition when using regular UEFI (i.e. not Apple's insane firmware):

1. Install Ubuntu. You'll want to create a 256M /boot (unencrypted), a LUKS container with LVM for /.


2. Disable SecureBoot. Hopefully I will figure out how to fix this later.


3. Boot the system to prove that it boots correctly.


4. apt-get purge grub-efi-amd64-signed (the signed grub image does not have LUKS/cryptodisk support)


5. Copy the contents of /boot somewhere, and note the device (say /dev/sda2 for this example).


6. cryptsetup luksFormat /dev/sda2 -c aes-xts-plain64
   DO NOT install LVM here; grub2 refuses to allow FS writes to LVM volumes, which is needed for recordfail.


7. Create an entry in /etc/crypttab for the new LUKS container. We'll assume you called the device-mapper node "boot_crypt".


8. /etc/init.d/cryptdisks-early start (prove that crypttab works)


9. mkfs.ext4 /dev/mapper/boot_crypt -L boot (or whatever filesystem you want here)


10. Edit /etc/fstab to point /boot to /dev/mapper/boot_crypt.


11. Copy the saved files from step 5 into the new /boot.


12. echo 'GRUB_ENABLE_CRYPTODISK=y' >> /etc/default/grub


13. grub-install -v (verify that grub-mkimage is called with luks/cryptodisk modules included)


14. update-grub


15. Reboot. Grub should now prompt to unlock the disk before showing the boot menu. For extra credit, set up LUKS keys for automount, since the only thing unencrypted on your HDD is grub, and (in theory) you could stash the rootfs LUKS keys in the initramfs. If I figure out how to make this work with SecureBoot I'll update this post.

Encrypted root and /boot on AppleEFI on Ubuntu 14

Hi all,

Here's how you install Ubuntu 14 with a LUKS-encrypted / and /boot partition when using Apple's "quirky and fun" EFI:

1. Insert a USB stick, and boot the installer into "Try Ubuntu" mode (you need to be able to start an xterm before rebooting).


2. Install Ubuntu. On the hard disk, you'll want to create a 64M empty partition, a 256M /boot (unencrypted), and a LUKS container with LVM for /. Format the USB stick as an EFI system partition and let the installer put files there.


3. BEFORE rebooting the installer, change the HDD's empty 64M partition's type code (call it /dev/sda1) to Apple Boot (gdisk type code AB00) and format it HFS+.


4. Mount the new / to /mnt, and the new /boot to /mnt/boot. (The installer might just leave these two filesystems mounted at the end of the installation; I don't remember.


5. Mount the new Apple Boot partition (on the HDD). We'll say you mounted it to /mnt/boot/efi.
   
6. touch /mnt/boot/efi/mach_kernel


7. mkdir -p /mnt/boot/efi/EFI/ubuntu/ /mnt/boot/efi/System/Library/CoreServices/


8. cd /mnt/boot/efi/EFI/ubuntu/


9. ln -s ../../System


10. touch mach_kernel


11. chroot /mnt/ grub-install -v (in theory grub2 knows how to generate Mac-compatible files, though it puts them in the wrong location)


12. Reboot to Mac OSX.


13. diskutil mount /dev/disk0s1


14. Open Preferences, Startup Disk, select the Ubuntu install.


15. Reboot the system to prove that Linux boots correctly.


16. apt-get purge grub-efi-amd64-signed (the signed grub image does not have LUKS/cryptodisk support)


17. Copy the contents of /boot somewhere, and note the device (say /dev/sda2 for this example).


18. cryptsetup luksFormat /dev/sda2 -c aes-xts-plain64
    DO NOT install LVM here; grub2 refuses to allow FS writes to LVM volumes, which is needed for recordfail.


19. Create an entry in /etc/crypttab for the new LUKS container. We'll assume you called the device-mapper node "boot_crypt".


20. /etc/init.d/cryptdisks-early start (prove that crypttab works)


21. mkfs.ext4 /dev/mapper/boot_crypt -L boot (or whatever filesystem you want here)


22. Edit /etc/fstab to point /boot to /dev/mapper/boot_crypt.


23. Copy the saved files from step 17 into the new /boot.


24. echo 'GRUB_ENABLE_CRYPTODISK=y' >> /etc/default/grub


25. grub-install -v (verify that grub-mkimage is called with luks/cryptodisk modules included)


26. update-grub


27. Reboot to Mac OSX.


28. diskutil mount /dev/disk0s1


29. Open Preferences, Startup Disk, select the Ubuntu install. Again.


30. Reboot. Grub should now prompt to unlock the disk before showing the boot menu. For extra credit, set up LUKS keys for automount, since the only thing unencrypted on your HDD is grub, and (in theory) you could stash the rootfs LUKS keys in the initramfs. Macs don't support SecureBoot, at least not the 2012 models.

N.B. The Apple firmware will try to boot whatever the HFS+ startup file points to; using efibootmgr does no good here. If you rewrite the boot.efi file the safe way (write boot.efi.new, mv boot.efi.new boot.efi) you'll have to set the startup disk in OSX again, because the "startup file" is really an extent map in the HFS+ superblock. Quite possibly OSX simply copies the contents of boot.efi into the blocks pointed to by the startup file when a Startup Disk is set.