It worked perfectly
, congratulations and thanks again and for solving this case, what is more in a much easier way that I could imagine.
Let me share herebelow several points I've gone through:
1. Detailed feedback on my experience of signing Virtualbox kernel modules with your method on an Asus 2019 Laptop
- As mentioned previously I had already followed your tutorial #2360
(Appendix 1 - Method A) and then had already everything settled in /boot directory as required.
- It worked exactly as your described to sign kernel modules for VirtualBox 6.0
- I updated to VirtualBox 6.1.4, and with this version there is no
file in the
folder. Therefore, simply running the following was enough to make it work:
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxdrv.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetflt.ko
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/misc/vboxnetadp.ko
Do not open VB
2. Is there a "vulnerability" in our encryption strategy (quite light anyway if so, as only related to an expected effect of boot directory encryption)?
The "Secure Boot violation error" I caused by running
was eventually easy to fix. I've come to assume it was due to that command which updated the file grubx64.efi, so I remembered the warning you give in your tutorial #2360 saying that everytime grub will be updated, it will be necessary to sign again the files. Although all the Linux Mint updates of the last 6 months (including kernel or grub updates which perform
command) has never required me to sign the EFI file again so far, I followed below steps as indicated in your tutorial (based on Appendix A - Method 1) and it was enough to remove the Secure Boot error.
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Mint --boot-directory=/boot --modules="all_video boot btrfs cat chain configfile crypto cryptodisk disk diskfilter echo efifwsetup efinet ext2 fat font gettext gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus loadenv loopback linux linuxefi lsefi lsefimmap lsefisystab lssal luks lvm mdraid09 mdraid1x memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png raid5rec raid6rec reboot search search_fs_uuid search_fs_file search_label sleep squash4 test true verify video zfs zfscrypt zfsinfo" --recheck
cp -b -f /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Mint/grubx64.efi /boot/efi/EFI/Mint/grubx64.efi
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/BOOT/bootx64.efi /boot/efi/EFI/BOOT/bootx64.efi
sbverify --cert db.crt /boot/efi/EFI/Mint/grubx64.efi
sbverify --cert db.crt /boot/efi/EFI/BOOT/bootx64.efi
However, it makes me wonder whether this could be the way of a possible attack to our encryption strategy.
Usually, with the dual boot FDE (directory /boot included) I set up adapting other great tutorials of yours
), directly after pressing the Power button comes a LUKS screen asking for Master Password. Then it boots on GRUB which offers the choice of booting to Linux Mint (bootx64.efi), Linux Mint again (named Ubuntu for some reasons - grubx64.efi), Windows Bootloader, or System setup (Asus UEFI Setup).
With the error coming up, after pressing Power button, it first displayed the error screen (red screenshot attached to my penultimate post), and it was necessary to press ENTER so that the LUKS screen would appear (and then as usual, except that the boot option "Ubuntu" - grubx64.efi was leading to displaying the error again, since it was the file which was tampered with and which Secure Boot therefore prevented the execution).
But if you were pressing ESCAPE instead of ENTER at the error screen, then it was displaying the boot order menu (related to Asus UEFI, so I guess ESCAPE would be the "F something" key with other brand), which was then allowing to somehow bypass the boot partition encryption. More precisely, it displayed the boot options, so:
- if you clicked on Linux Mint, then it would display LUKS screen, then usual GRUB menu once master password was entered;
- if you clicked on Windows Bootloader, it was booting to it directly (no LUKS screen);
- if you clicked on System Setup it booted on Asus UEFI Setup.
In normal circumstances (without the error screen), pressing ESCAPE (i.e. at LUKS screen) displays GRUB CLI recovery Menu.
Asus UEFI Setup
allows to define two different kind of passwords: an Administrator Password which protects the access to the Asus UEFI Setup utility, and a User Password that is asked everytime at boot time (after pressing the power button). As per the recommendation you provide in the tutorial #2360, I had set up an Asus UEFI Admin Password to protect the ability of turning Secure Boot off. However I did not set up a User Password as I thought one password at boot (the one to be entered at LUKS screen) would be enough.
I nevertheless tried all cases when having the error:
To summarise, I am under the impression that with the current Dual Boot FDE install (/boot included) [there might be the same issue with a "simple boot" install, except that it would therefore not offer the Windows Bootloader option], tampering with an EFI file in order to provoke a Secure-Boot violation would allow bypassing the effect of boot directory encryption in granting access to the boot menu via UEFI utility interface. For now, the only means I see to address this issue is adding a UEFI User Password to prevent this behaviour. It is not very convenient as it adds up to boot time (2 passwords...).
- With Admin Password only, it displays the error. if you press ESCAPE, then it asks for Admin Password. if you have the good password it brings you to the UEFI boot menu (i.e. bypass of boot encryption via LUKS). If you have wrong password, it still brings you to the same boot menu, except that if you choose System Setup item, then you have access to a limited version of the utility (e.g. you cannot turn off Secure Boot).
- With User Password only, Asus UEFI utility asks immediately for a password after pressing the Power button. If you had pressed ESCAPE key, if you have the good password it brings you to the boot menu (i.e. bypass of LUKS screen). If the password is wrong you are blocked there.
- With Admin + Password, a User Password prompt appears at boot, but if you enter Admin Password it works as well (grants you all priviledges to change System Setup if you had pressed ESCAPE key and select System Setup in UEFI boot menu).
3. Two theoretical questions (not essential - I do not want to abuse of your time...)
Following your tutorial about custom keys and trying to figure out how to solve the issue discussed hereinabove helped me to better understand the logic of secure boot, even though I am still far from mastering it.
I write here a few "theoretical" questions in case you would be able to consider them:
- Is there a reason why your tutorial #2360 does not include the flag
grub-install as indicated here for example ? In practice I do not mind as I did not encounter any particular issue due to this so far.
- What is the difference between
sign-file tools? Do you think it would have been possible to sign Grub EFI files with
sign-file or VirtualBox kernel modules with
Hmmm sorry for such a long post and thanks again.