GRUB cannot find encrypted boot partition

Question

Arch Linux Installation (On encrypted LVM) and attempt to encrypt boot partition.

It's something that bothers me having a "Full disk encryption" with a non encrypted boot partition. This question is about what may have gone wrong in my installation, but I would appreciate very much thoughts about having or not having a non encrypted boot partition. Is indeed a unencrypted boot partition a vulnerable point on the system? What is still vulnerable? Encrypt the boot partition does make its part in better securing the system?

That pointed out, I intend to do my best in detail the necessary information about the installation and the system to help to solve the question why grub cannot find the boot partition, but I too appreciate support in understand what is needed to be detailed, I just have hints about what may be determinant and how the system boot process works, I'm like in the process of exploring the linux system, experimenting it, and learning from it.

On start up after installation

Welcome to GRUB!

error: no such device: dbf12ef6-156f-43ac-980d-ee41ao17b917
error: unknown filesystem.
Entering rescue mode...
grub rescue>

Installation

# iwctl to connect to a wifi
root@archiso ~ # iwctl

# update package repository index
root@archiso ~ # pacman -Syyy

# securely erase the disk
root@archiso ~ # dd if=/dev/urandom of=/dev/sda bs=4096 status=progress

# partition the table
root@archiso ~ # fdisk /dev/sda
    g (GPT Partition Table)
    /dev/sda1 EFI System (type alias 1) +500M
    /dev/sda2 Linux FileSystem (type alias 20) +500M
    /dev/sda3 Linux LVM (type alias 30) +100%FREE

root@archiso ~ # fdisk -l /dev/sda
#result
Disk /dev/sda: 298.09 GiB, 320072933376 bytes, 625142448 sectors
Disk model: Hitachi HTS54503
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes /4096 bytes
Disklabel type: gpt
Disk identifier: A9C36FBB-D67F-5840-9BD9-28326588F6BA

Device       Start       End       Sectors      Size    Type
/dev/sda1     2048   1026047       1024000      500M    EFI System
/dev/sda2  1026048   2050047       1024000      500M    Linux filesystem
/dev/sda3  2050047 625142414     623092367    297.1G    EFI System

root@archiso ~ # lsblk -f

NAME    FSTYPE      FSVER    LABEL    UUID    FSAVAIL    FSUSE%    MOUNTPOINT
loop    squashfs    4.0                             0      100%    /rub/archiso/sfs/airootfs
sda
-sda1   vfat        FAT32             7D44-F492
-sda2   crypto_LUKS 2                 60f94adc-1e6f-425d-a120-4888fa9bacd3
-sda3   crypto_LUKS 2                 5ab19132-685d-479b-8425-acaa133ed7a8

# format EFI partition
root@archiso ~ # mkfs.fat -F32 /dev/sda1

# encrypt boot partition
root@archiso ~ # cryptsetup luksFormat /dev/sda2

# open encrypted boot partition
root@archiso ~ # cryptsetup open --type luks /dev/sda2 cryptboot

# format encrypted boot partition
root@archiso ~ # mkfs.ext4 /dev/mapper/cryptboot

# encrypt LVM partition
root@archiso ~ # cryptsetup luksFormat /dev/sda3

# open encrypted LVM partition
root@archiso ~ # cryptsetup open --type luks /dev/sda3 cryptlvm

# create physical volume
root@archiso ~ # pvcreate /dev/mapper/cryptlvm

# create volume group
root@archiso ~ # vgcreate volgroup0 /dev/mapper/cryptlvm

# create logical volume 
root@archiso ~ # lvcreate -L 50GB volgroup0 -n root

# format root filesystem logical volume
root@archiso ~ # mkfs.ext4 /dev/volgroup0/root

# mount root logical volume
root@archiso ~ # mount /dev/volgroup0/root /mnt

# create directory to mount the encrypted boot partition
root@archiso ~ # mkdir /mnt/boot

# mount the encrypted boot partition
root@archiso ~ # mount /dev/mapper/cryptboot /mnt/boot

#create /etc directory
root@archiso ~ # mkdir /mnt/etc

# generate fstab file (required for successful boot)
root@archiso ~ # genfstab -U -p /mnt >> /mnt/etc/fstab

# sanity check on file
root@archiso ~ # cat /mnt/etc/fstab

# /dev/mapper/volgroup0-root
UUID=71d35768-2e3b-4aad-bd88-313544742d72    /        ext4    rw,relatime             0 1

# /dev/mapper/cryptboot
UUID=dbf12ef6-156f-43ac-980d-ee41a017b917    /boot    ext4    rw,relatime,stripe=4    0 2

#install packages on file system
#(obs
#linux <defaultLinuxKernel> linux-lts <alternateLinuxKernel
#   -makes possibly a selection at the start process of the computer in which you can set the alternate kernel, which is very useful if you run into a problem
#
#efibootmgt dosfstools os-prober mtools
#   -packages to support grub
#)
root@archiso ~ # pacstrap -i /mnt base base-devel linux linux-lts linux-headers linux-lts-headers networkmanager wpa_supplicant wireless_tools netctl openssh dialog lvm2 grub efibootmgr dosfstools os-prober mtools vim

# change to archroot to access in progress installation to make additional changes
root@archiso ~ # arch-chroot /mnt

# enable openssh NetworkManager by default (start automatically at boot time)
[root@archiso /]# systemctl enable sshd NetworkManager

# edit the very specific file /etc/mkinitcpio.conf
# line -- HOOKS=(base udev autodetect keyboard keymap consolefont modconf block lvm2 encrypt filesystems fsck)
[root@archiso /]# vim /etc/mkinitcpio.conf

# run mkinitcpio -p against whatever kernel decided to go along with
[root@archiso /]# mkinitcpio -p linux
[root@archiso /]# mkinitcpio -p linux-lts

# set time zone
[root@archiso /]# ln -sf /usr/share/zoneinfo/Brazil/East /etc/localtime

# generate /etc/adjtime
[root@archiso /]# hwclock --systohc

# Localization - edit /etc/locale.gen uncommenting appropriate locale
[root@archiso /]# vim /etc/locale.gen

# generate the locale(s)
[root@archiso /]# locale-gen

# set the LANG variable in a file named /etc/locale.conf
[root@archiso /]# vim /etc/locale.conf

# set the keyboard layout in a file named /etc/vconsole.font
[root@archiso /]# vim /etc/vconsole.conf

# configure bootloader (grub has the most compatibility, applications such as timeshift have an issue when not using grub)
# (obs
# GRUB_ENABLE_CRYPTODISK=y
# GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 cryptdevice=/dev/sda3:volgroup0:allow-discards quiet"
# )
[root@archiso /]# vim /etc/default/grub

# create file for EFI information (files that are required for booting the system)
[root@archiso /]# mkdir /boot/EFI

# mount the EFI System partition
[root@archiso /]# mount /dev/sda1 /boot/EFI

# install grub bootloader on the hard drive
# no errors were reported
[root@archiso /]# grub-install --target=x86_64-efi --bootloader-id=grub_uefi --recheck

# create directory /boot/grub/locale
[root@archiso /]# mkdir /boot/grub/locale

# copy file into directory
[root@archiso /]# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo
    
# Generate GRUB's configuration file:
[root@archiso /]# grub-mkconfig -o /boot/grub/grub.cfg

# create a swap file
# (obs
# it's preferable to create a swap file instead of a swap partition because it is easier to change the size of swap just deleting and recreating the file with a bigger size whereas with a swap partition. With a swap partition it's needed to resize the partitions which is a lot more risky
# )
[root@archiso /]# fallocate -l 4G /swapfile

# adjust the swap file permissions to be more restrictive
[root@archiso /]# chmod 600 /swapfile

# Make swap
[root@archiso /]# mkswap /swapfile

# create a backup of fstab file
[root@archiso /]# cp /etc/fstab /etc/fstab.bak

# Make swap activate as soon as computer is started adding to fstab file
[root@archiso /]# echo "/swapfile none swap sw 0 0" | tee -a /etc/fstab

# sanity check on file
[root@archiso /]# cat /mnt/etc/fstab

# /dev/mapper/volgroup0-root
UUID=71d35768-2e3b-4aad-bd88-313544742d72    /        ext4    rw,relatime             0 1

# /dev/mapper/cryptboot
UUID=dbf12ef6-156f-43ac-980d-ee41a017b917    /boot    ext4    rw,relatime,stripe=4    0 2

/swapfile none swap sw 0 0

# install micro code package for the actual CPU (if AMD cpu - amd-ucode; elseif intel cpu - intel-ucode)
[root@archiso /]# pacman -S intel-ucode

# package to facilitate a desktop environment
[root@archiso /]# pacman -S xorg-server

# consider installing a video driver, if intel or AMD gpu - mesa; elseif NVIDIA gpu - nvidia nvidia-lts nvidia-utils
[root@archiso /]# pacman -S mesa

# back to arch linux install media
[root@archiso /]# exit

# umount -a
root@archiso ~ # umount -a

# poweroff or reboot
root@archiso ~ # poweroff

Straightforwardly, this was the installation. Writing the question, I noticed that GRUB tries to find device id dbf12ef6-156f-43ac-980d-ee41ao17b917

error: no such device: dbf12ef6-156f-43ac-980d-ee41ao17b917

That happens to be the device id of /dev/mapper/cryptboot as it is in the file /mnt/etc/fstab or just /etc/fstab and was mounted on /boot during installation

# /dev/mapper/cryptboot
UUID=dbf12ef6-156f-43ac-980d-ee41a017b917    /boot    ext4    rw,relatime,stripe=4    0 2

Which, as it seems to me, just exists after the command root@archiso ~ # cryptsetup open --type luks /dev/sda2 cryptboot

Might this be the problem? Any hint in what may be the problem, where I went wrong and how to fix it?

I'd appreciate very much, any lacking information I'll be on to better detail.

Answer 1

As TelcomM has suggested, I thoroughly had reviewed both links in Arch Wiki before the installation, but I have missed one specific note:

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

Even though that do not respond the question "why grub cannot find the encrypted boot partition" in my installation, neither solves the problem in making grub find the partition, it seems to me that there's no point in having on same disk two distinct partitions encrypted, one for system's root and another for system's boot.

Having just one encrypted partition with /boot under system's root worked right and the system booted properly.

With that pointed out, also seems to me that this solution is perfectly sufficient to address my bothering in a pretended "Full disk encryption" with a non encrypted boot partition. So, the question appear solved to me as regarding the /boot partition.

Yet, in this installation we still a have a "bothering" non encrypted EFI system partition, and remains to me the question "being this partition non encrypted does make it a likely vulnerable point on system?"

I appreciate very much any points on discussion.

Answer 2

The Arch Wiki has specific instructions for configuring your boot partition and grub to be compatible with each other: Encrypted /boot partition - Arch Wiki

Did you have a chance to thorougly review that and ensure that you've gone through the steps outlined there when you created your encrypted boot partition?

There's also this Arch Wiki Guide on Full System Encryption

Is indeed a unencrypted boot partition a vulnerable point on the system?

I don't know enough about what's on /boot to say for sure, but I doubt there's going to be a lot there that would create additional risk of someone breaking the encryption on the rest of your disks.

Maybe an attacker could find information about what kernel you're running.

Answer 3

# encrypt boot partition
root@archiso ~ # cryptsetup luksFormat /dev/sda2

change to:

# encrypt boot partition
root@archiso ~ # cryptsetup --type luks1 luksFormat /dev/sda2

grub2 does't support fully luks2 encryption which is set by default option when you format partition. Also same thing for other partition which should cooperate with grub. :)

Answer 4

I don't see from the information presented why GRUB does not boot. You are right that grub cannot found "dbf12..." device because it is available only after decrypting boot. However, GRUB should deduce that it is located in encryption partition and include in core image encryption modules which can decrypt boot partition. Some hints: check /etc/default/grub that it enables cryptodisk (GRUB_ENABLE_CRYPTODISK=y) and check /boot/grub.cfg. In rescue mode you can try to unlock boot partition via cryptomount command (although it may be unavailable in rescue mode - it depends whether cryptodisk extension was really enabled). You can run grub-install in verbose mode (-v) to check what path does it use to install modules (verbose output provides additional information which can point to the root of the problem).

As a possible solution you can install grub on unecrypted EFI partition with the option "--boot-directory=/boot/EFI" (assuming it is mounted to /boot/EFI which seems to be your case). In this setup grub core image and all modules are located in unencrypted partition. Even if grub.cfg is misconfigured you can manualy load linux from grub console. Strictly speaking, this is not answer to the question (because GRUB can be installed the way you tried), but it seems you are evaluating different ways to encrypt disk.

Regarding the general question of boot encryption. In case of GRUB (not all bootloaders support encryption) there are several 'degrees' of FDE, they differ in the amount of boot files which are hidden in ecnrypted partition.

1. GRUB, kernel and initramfs image are located in unecrypted partition, likely EFI (separate partition can be created to contain these files, but there is no need to, so for simplicity all boot files can be kept in EFI partition - 500MiB should be enough). In this setup attacker can tamper kernel or initramfs image, anyone with access to disk can wipe out these files. Password should be typed after loading kernel or provided with keyfile which should have separate protection. Answering your question - in this setup vulnerable points of system are kernel+initramfs+GRUB.

2. GRUB is located in unencrypted EFI partition, kernel and initramfs are located in encrypted /boot folder which is part of root partition. In this case password should be provided during GRUB boot before loading kernel. It should be also provided after kernel boot, but for simplicity keyfile can be embedded in initramfs (in option 1 this is not possible because initramfs is unprotected). In this case attacker cannot tamper kernel or initramfs image, but he/she can (in theory) tamper grub core file or module (vulnerable points) in order to 'steal' password.

3. GRUB core image and encryption modules are located in unencrypted EFI partition, other parts of GRUB - in encrypted root partition. In this setup GRUB core image (with the help of several crypto-related modules 'embedded' together in a single EFI file) asks password to decrypt the rest of itself and also to access kernel and initramfs images. In this case attacker can tamper only core image (for simplicity 'EFI file'), so it should be protected by other means, like UEFI SecureBoot. Still, even without SecureBoot the surface of attack decreased from 'any GRUB file' in option 2 to 'GRUB core file'.

So, in theory you can protect the full chain GRUB core image -> GRUB modules -> kernel image + initramfs with Secureboot enabled. However, it really depends on percieved threats and which parts of boot process you want to protect. Some people may consider option 3 as overkill. It should be also noted that in some jurisdictions the state can lawfully force you to surrender password, in other countries the state can literally 'force' (unlawfully) you to surrender password. Taking this into account - the state will not bother writing GRUB malware, for protecting data from general public option 1 is sufficient. This is really big and general topic which is goes somewhat outside of original question.