Mint 17.X to 21.X and LMDE 6 Full Disk Encryption (directory /boot included) - Using LUKS2, SecureBoot & TPM 2.0+PIN

[linux22]

Hello questionbot, if you have installed my FDE tutorial 2438 PC UEFI + HDD GPT + EFI STUB + tutorial 2496 (ex 2360, Secure Boot) you can do these test:

1) Temporary disable Secure Boot and try to boot your system.

2) If your system boot normally with Secure Boot disabled check if you have correctly installed the following file:
"/etc/initramfs/post-update.d/objcopy_update_hook".
The file should contain the commands listed in the example reported at the end of Step 3 of my tutorial 2438. Remember that the file content should be different if you have installed Linux Mint 20 or previous Linux Mint versions !

3) Check that your "/boot/efikeys" directory has been populated with all your Secure Boot own Custom keys.

4) PAY ATTENTION that the command "objcopy" inside file "/etc/initramfs/post-update.d/objcopy_update_hook" is correctly formatted (no LF inside the
command) !!!

5) Launch this command: "sudo /etc/initramfs/post-update.d/objcopy_update_hook" , then check that it ends without error. This command build a new copy of your kernel.efi and bootx64.efi files (these files are build from your last vmlinuz, initrd.img and boot/efistub/cmdline.txt files. When the command ends you should see a message like "Signature verification OK", or something like that.

6) Now try to reboot your PC. If it boot correctly re-enable Secure Boot and try to reboot your PC again. If it boot correctly your system is OK.


Remember to check the correct update of your kernel.efi and bootx64.efi files at every kernel e/o initrd update/upgrade !!!


Please keep me informed about your progress.

Regards.

linux22

[questionbot]

Thanks... I was more just letting you know. I went back to Void Linux already. My mint test was not positive.

[dobp]

Hello dobp. I have read your message and, as you said in your EDIT note, the problems with GRUB is the most important reason because I have switched to EFI STUB. In my past tutorial concerning Linux FDE I was always dealing with GRUB with great difficulties. So when I switched to UEFI I have found an alternative to bypass GRUB and boot Linux with a simple and reliable new method, EFI STUB. You can try this new method also on PC with dual boot W10+Linux but your PC UEFI Boot Manager must be able to deal with many boot .efi file. Most PCs with UEFI firmware have a Boot Manager that can be started pressing a Fn key at start-up (typically F8, F10, F12 ecc.). Once pressed the Boot Manager Fn key at boot-up the system load a list of all bootable .efi images found in EFI boot partition. You can then select Mint or W10 and then press Enter to start the selected OS.

About the error you get after updating GRUB I do not know how to solve your problem. If you have installed Linux Mint FDE using my old tutorial (Dual Boot) I have no clue about the error you get. Anyway you can try to sign with your own Custom keys your kernel image with 'sgsign' command and all your kernel module using 'scripts/sign-file' script but I can not say if that will work correctly.

UPDATE:

You can read more about signing Linux kernel & modules for Secure Boot at the following links:

- https://wiki.debian.org/SecureBoot

- https://ubuntu.com/blog/how-to-sign-thi ... ecure-boot

- https://wiki.gentoo.org/wiki/Signed_ker ... le_support


Very interesting the first one, especially paragraph "Secure Boot limitations" !


Regards.

linux22

Hello linux22,

Thank you very much for your kind support as always. I did not address the issue yet although I still plan to do it (try and fix the current error when SB is enabled). I will keep you posted here.

Regards,
dobp

[linux22]

Hello dobp, I have read your last post. At the moment I am working on a new solution for Dual Boot Windows 10 + Linux Mint FDE.

As explained in my tutorial at https://community.linuxmint.com/tutorial/view/2191 the new solution will be:

Dual boot for Windows 10 + Linux Mint 20.X with EFI STUB loader
Linux Full System Encryption (directory /boot included)
PC with UEFI & HDD with GPT and Boot Manager ‘systemd-boot’
Solution using the Linux Extended Boot Partition (a.k.a. XBOOTLDR)

Release within the end of November 2020

When using the EFISTUB+objcopy tools you get an .efi executable, containing kernel(with modules)+initrd+kernel’s command-line parameters,
that can be signed for Secure Boot with a single shot.

Regards.

linux22

[linux22]

Hi folks, tutorials "Linux Mint with Full Disk Encryption, directory /boot included - PC UEFI & HDD GPT - Booting with EFI STUB loader" have been updated today. This release include "Appendix F (Experimental) - How to enable LUKS AutoUnlock via TPM2.0". This configuration works similar to Windows Bitlocker. Once correctly configured the unlocking of your Linux FDE system is performed at boot-up by the TPM module of your PC, which release the key for automatic unlock of the root LUKS partition, performed by the initramfs scripts.
See details at:
https://community.linuxmint.com/tutorial/view/2438

[throwaway_5521]

Hey, sorry for bumping a slightly old thread

I would like to thank OP (linux22) for giving us instructions on how to do a FDE and secure boot activation in linux mint.

However, is there a method on how to sign NVIDIA/Radeon Drivers using my keys/certificates that i created when setting up secure boot on some laptops without relying on shim/MOK? and if possible, include that in your own guide linux22?

once again, thanks for the guide.

[linux22]

Hello throwaway_5521, I have read your message. I cannot test the installation of NVIDIA drivers on my systems because I do not have PCs with NVIDIA card installed.

Anyway I have done some searchs and I have found some interesting NVIDIA documents concerning installation of NVIDIA Linux drivers and how to sign them with your own custom keys.

Below I leave 2 links from nvidia.com named "Installing the NVIDIA Driver" and "Listing of Installed Components". Pay attention to paragraph "Signing the NVIDIA Kernel Module" within the first document (see link 1 below), where you can find the correct procedure for signing NVIDIA kernel modules during the installation process.

1) https://download.nvidia.com/XFree86/Lin ... river.html
2) https://download.nvidia.com/XFree86/Lin ... nents.html

If that procedure does not work you can do a manual signing of your NVIDIA kernel modules (i.e nvidia.ko and others) following the instructions listed in post 66 of this topic and the tips reported within the second document (see link 2 above).

The manual signing will be something like that:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /boot/efikeys/db.key /boot/efikeys/db.crt /lib/modules/$(uname -r)/pathtonvidiadrivers/nvidia.ko

where the correct 'pathtonvidiadrivers' is that where the NVIDIA kernel drivers of your Linux system are located !!!

Please keep me informed about your progress.

Regards.

linux22

[lofi]

Hello linux22 and everyone !

I post here again for 2 things :
- (mainly) To share tips (and maybe one improvement) to help people who have followed your old tutorial to adapt their old configuration to your new work / updated tutorials (for example, how to add systemd bootloader without starting from 0, and maybe one bug report)
- to maybe ask a couple questions mostly out of curiosity
- to thank you

1) Thank you linux22 ! (can I call you Stefano? I see you give your full name in your links) You are a Godsend. Where can I send you a substantial tip? I've used your tutorial and didn't touch it for almost 3 years, never had a problem! What I like best is how humble you are, and it shows even more now that you give all the sources you started your work from, very helpful!

2) Sharing tips after my work on "switching" from your old (2438) to new, updated (2438) tutorial.
Recently I've wanted to get a verbose Mint boot (no splash screen, no quiet) as I had this on my previous linux install (and I don't care about that small security risk). Took me some time to realize why I couldn't do it like on a non secure-boot system. Once I found cmdline.txt, I removed `quiet splash` but it changed nothing. Of course, I had read your instructions without understanding them. I didn't want to bother you here for that, so even once I understood it was a secure boot issue, I kept on searching the web alone. After long research, I finally guessed that I maybe could simply use a modified version of the script you wrote in `objcopy_update_hook`. But I was quite scared of ruining my secure boot (that I've used on my main computer for 3 years!) by typing commands that I didn't understand, and out of their original context. So I read about objcopy, sbsign... The objcopy command seemed weird, I thought it had no infile and outfile, so I thought they were implied from the context of the command / from where your script was run from. I noticed many chroot to /mnt in your tutorial, I thought I had to do something similar (bad idea!). Another idea was that I had to understand Mint kernel update hooks... I should have read the entirety of your updated tutorial, because I saw later that for a similar purpose, you said yourself that we could just run your update hook manually (with sudo, from anywhere) to update and sign everything.
So, my cmdline.txt was already modified for my desired changes, and your script did the rest! So I encourage everyone to use it manually if needed!
(thanks to your link to Matthew Bentley.link now I understand that objcopy is precisely made to protect cmdline.txt (etc) from tampering, by merging it with initrd.img and vmlinuz and signing the whole thing as an EFI standalone application (later I realized that you sum it up yourself somewhere in your tutorial, and/or here in the OP, and in this thread)

I also wanted to report a typo :

In this case the hook rebuild the 'kernel.efi' file only and if necessary sign it for Secure Boot.

It feels ridiculous now, but please put yourself in the shoes of outsiders who don't understand what they type : because of the typo, what I first understood was : the objcopy_update_hook rebuilds the kernel.efi, and if necessary, SIGN it for secure boot. So I thought the rebuilding was easy, already done by the script, but "damn, then I have to find if signing it is necessary, and if so, how to do it myself". Well, of course you meant that after rebuilding, the script signS it if necessary! (I usually don't care about typos, but this one made me scratch my head!)

Also, while searching for my answers in your new tutorial (honestly, in the beginning I just wanted to find the exact tutorial I had followed, as I'm still on Mint 19), I found an interesting appendix. The one about installing systemd-boot. You say that it allows us to choose between current kernel and second to last kernel. Which is very cool, as, I admit it, the only problem I've had with our setup is when there was a bad linux kernel once, about a year ago. Everywhere on the web I saw that it was easy to boot from another kernel, but not with "our" configuration. So I wanted this! (same choice as with Grub, no secure boot)

This is where I think that with my experience, I can give a few tips for those like me who would like to change their secure boot and understand the differences between your old and new tutorial. In the appendix, I copied all your commands to install systemd-boot, create the loader.conf, create the EFI boot entries... But it didn't work. So here's what I did,
- I'm not sure if it's because my Mint 19.1 is too old or too new (many packets still get updated), but I read that in the loader.conf it is now recommended to write "default mint" instead of "default mint.conf"

source: - https://systemd.io/BOOT_LOADER_INTERFACE/ When boot loader entries are defined through Boot Loader Specification drop-in files the identifier should be derived directly from the drop-in snippet name, **but with the .conf** (or .efi in case of Type #2 entries) **suffix removed**.

This fixed one of my problems, as the Mint entry became the actual "default" (apparently the line wasn't parsed correctly, "second last" was default)
Also, I had to remove the tabs from `loader.conf`, and replace them with spaces. The documentation is not clear on this (bug? update?) but it fixed other problems I had. But I could not fix 4 remaining errors of "unknown line" for console-mode, random-seed-mode, auto-entries and auto-firmware (`sudo bootctl list` shows the errors). I searched extensively and read that "boolean" meant any of "no, n, false, f, 0, or off". But whatever the spelling, in the end the parser still can't parse those 4 "unknown lines". But the most important line (security-wise), "editor no", is understood. (timeout is also understood). And apparently the absence of the 4 others didn't cause problems.
But I had another problem, took me some time to realize the answer is I had to sign the systemd-bootloader (systemd-bootx64.efi) itself! When I tried to find what exact command I had to run, I had the idea to Ctrl+F your .pdf, and I finally realized that the systemd-bootloader commands in your Appendix are of course meant for people who have typed all the commands of the main part above... In fact, the tutorial said to sign the systemd-bootx64.efi long before the appendix, in the main part. This is why I was stuck a long time! (I had typed the command of the main part 3 years ago, when you hadn't implemented systemd-bootloader)

So then I could reboot, and not only get my verbose boot, but also the bootloader menu I wanted, with "last kernel" and "second to last kernel". But I realized, before actually needing a second to last kernel, that it still wouldn't actually work as it was : I wondered how the current kernel magically became the second.last.kernel.efi boot option... So I searched again, and after some time I guessed right that the answer was probably (again) in your tutorial itself, somewhere... And I found that your code for objcopy_update_hook had changed, that at the beginning you had added the commands to archive the old kernel, to make it available for the second last kernel EFI boot option. So I added these commands, but now I have to wait for a kernel update to test this. (but I think now I'm good!)

(NB : I'm aware that this probably won't help many people, as probably, few people like me changed nothing to their install since your old tutorial "2438", and maybe now the new linux Mint has an installer offering EFI secure boot with /boot encrypted, so all this is not needed anymore ? But maybe a few people will face the same problem)

3) Totally optional questions, out of curiosity :
- why do we have these strange paths efi/EFI in /boot ? Why is it necessary?
- what do you mean "kernel warehouse" in one info prompt in the update hook script ? Does it mean "kernel warehouseD ", as in "the task of archiving the old kernel was completed OK " ? Or is it a technical term ?


4) I have only one serious question, but I'll keep it for later as this was already long enough.

So, my main point was that it's really cool that you added the sources for your work, because when you update your tutorials, those sources are much needed : we can't make any small change to your tutorials unless we fully understand everything that's happening... I know you do it for free (and I'd like to tip if you provide a way to do it!), so my point was not to ask for tons of comments around all your commands, nor ask for a specific tutorial for all use cases (it's almost infinite). I just wanted to share a couple findings that might be of help for someone.
Thanks again for your robust tutorials and scripts, which have protected my Mint laptop for almost 3 years! (burglars tried to break into my house 2 years ago! My thinkpad was ready for them and their rootkits!)

lofi / Stéphane

[mike28]

Hello,
by chance does this method work also with a normal BIOS and MBR partitioning, or can it work with a normal BIOS and GPT partitioning?
What can I do to let it works also with a normal BIOS?

[lofi]

Hello,

Hi and welcome!
Check the OP of this thread,

linux22,

You can read my guide/tutorial 'Linux Mint with Full Disk Encryption, directory /boot included - PC with BIOS & HDD with MBR' on Linux Community at: http://community.linuxmint.com/tutorial/view/2026

- lofi.

[linux22]

Hello lofi and mike28, I have read your messages. I am sorry but at the moment I am very busy.

I think I will replay to your questions within the end of this month.

Anyway the configuration using EFISTUB does work with UEFI firmware ONLY !

Regards.

linux22

[lofi]

hi linux22 !
Thanks for that post, nothing urgent for me, was just curious.
Actually today I've had the first opportunity to test the warehoused "second last kernel", and it works like a charm!

Excuse my french, but, bon courage for your work!
- lofi

[linux22]

Hello lofi, sorry, I know I am late but now I am ready to answer your questions and perhaps to make myself more clear about the
philosophy of my technical solution concerning Linux Full Disk Encryption (FDE) on PC with UEFI firmware using EFISTUB loader.

You know you can not setup an invulnerable PC but you can choose solutions that make the life of the BAD GUYS
more difficult.

My first tutorial concerning Linux Full Disk Encryption on PC with UEFI firmware was based on GRUB, the most important and
more featured tools for Linux booting. This tools is very cool and has the better configuration capabilities when you deal with a
standard Linux installation. But when you need a tools for managing Linux with Full Disk Encryption and pre-boot authentication
GRUB turn itself to a nightmare. I have spent a lot of nights attempting to fix its configuration, especially after a GRUB update
and/or upgrade. I think that this is due to the relative poor attention and interest in Linux with Full Disk Encryption installations.

So I looked around and I found 2 other tools: EFISTUB loader and systemd-boot.

Those little and spartan peaces of software solved all my problems configuring Linux Full Disk Encryption on PC with UEFI
firmware. With EFISTUB loader+objcopy I can build a standalone efi bootable file containing everything we need for the booting
process.

I better explain these topics in the Preface of my tutorial "Dual boot for Linux Mint 20.X (*) with EFI STUB loader + Windows 10
at: https://community.linuxmint.com/tutorial/view/2191.

But now let's talk about the guidelines of Linux Full Disk Encryption on PC with UEFI firmware:

1) the first step for Linux encryption is yet present in Ubuntu, Mint and other Linux distribution using Ubiquity as installation
framework. This Linux FDE solution is standard and very cool but it leave the boot directory and all its content unencrypted.

2) the second step is a custom installation with and encrypted partition containing the whole Linux filesystem, included the
boot directory. This Linux FDE solution is not standard and leave the only GRUB efi bootloader file unencrypted. This solution
was the choice of my early version of tutorial "Linux Mint XX.XX (but also Ubuntu YY.YY) Full Disk Encryption (directory /boot
included) Part 3 - PC with UEFI & HDD with GPT" at: https://community.linuxmint.com/tutorial/view/2061
This solution took a lot of my nights. Every time GRUB was updated and/or upgraded I was forced to test the new software and
often it did not worked anymore. Every time it was very difficult to fix the GRUB setup for FDE.

3) the third step is contained in the actual tutorial "Linux Mint XX.X and YY.X (but also Ubuntu) with Full Disk Encryption,
directory /boot included - PC with firmware UEFI & HDD with GPT partitioning scheme - Booting with EFI STUB loader"
at: https://community.linuxmint.com/tutorial/view/2438

Here I made 2 great changes:

1) I give up with GRUB and I choose EFISTUB loader+objcopy as boot loader
2) I choose systemd-boot as boot manager

In the tutorial you can see the PROS and the CONS:

PROS:

VERY FAST BOOTING
VERY FAST SHUTDOWN
VERY SIMPLE
SUPPORT FOR TYPE 2 LUKS ENCRYPTED PARTITIONS (LUKS2)
FULL DISK ENCRYPTION (FDE) REQUESTING ONLY ONE PASSWORD AT BOOT-UP
NO LUKS UNLOCK KEYFILES REQUIRED
WITHOUT OR WITH LVM (FOR ENABLING HIBERNATE FUNCTION)
NO MORE HEADACHE FOR GRUB UPDATING AND/OR UPGRADING
WORKS (WITH MINOR CHANGES) ALSO ON LINUX 32-BIT SYSTEMS (TESTED ON VIRTUAL MACHINES ONLY)


CONS:

POINTLESS AND/OR POTENTIALLY DANGEROUS FOR FULL DISK ENCRYPTION (FDE) SYSTEMS IF SECURE BOOT IS DISABLED
POOR CONFIGURATION OPTIONS (COMPARED TO GRUB)
NOT COMMON / NOT STANDARD
NEED GREATER EFI PARTITION SIZE (MINIMUM RECOMMENDED SIZE 1GB)


I think that here the PROS prevail on the CONS, but only if we implement a serious and strict policy concerning SECURE
BOOT and later, only when fully developed, also TMP2.

The logic behind this solution is:

1) We do not use GRUB, so we need a new boot loader. The EFI STUB loader seem our best choice but we are dealing
with a PC with firmware UEFI so we need to secure all files that remain outside of our encrypted partition.
The obvious move is to sign those files and enable Secure Boot. But you can not sign files that are not of binary type
and so the initrd file and the file containing the kernel's command-line parameters remain unprotected.

2) The solution come from link at: https://bentley.link/secureboot. Here we learn how to pack the linux kernel, initrd
file and kernel's command-line parameters together, using the objcopy tool. So the boot process is done by a single bootable
efi file, the unique remaining outside the encrypted partition.

3) When we sign this efi file and enable Secure Boot we are reasonable sure that an attacker can not tamper our kernel nor
our initrd file nor our kernel's command-line parameters.

4) This solution seems OK but it is NOT STANDARD and we need to rebuild our booting kernel efi file every time we install
a new kernel or we modify our initrd file or our kernel’s command-line parameters. So I build my own objcopy_update_hook
file. This executable file, allocated inside the /etc/initramfs/post-update.d directory, is run by the kernel when it detect a initrd
update in progress. The tasks performed by this executable file are:

a) detect if the actual initrd update is due to kernel upgrade, testing the $DPKG_MAINTSCRIPT_PACKAGE global variable

b) if a) is true rename the actual kernel efi bootable file as second kernel file and also save it inside the kernels warehouse
"/boot/efistub" directory for emergency rescue

c) rebuild the efi bootable kernel.efi file with objcopy tool

d) detect if the efi Secure Boot configuration is present testing if directory /boot/efikeys exist, and if so sign and verify the
last builded kernel.efi file

e) copy the last new kernel.efi file inside directory /boot/efi/EFI/Mint

f) sync the system

And finally the TPM chip.

There is a remote possibility that the BAD GUYS are very qualified and then they know how to re-flash the UEFI BIOS and thus
circumvent all our protections implemented with UEFI Secure Boot. If so they can disable Secure Boot, then wait for our next
access and finally steal our encrypted partition password with an "evil maid attack".

This possibility is very unlikely but anyway we can implement a protecting solution using TMP 2.0 and LUKS.

This solution use TPM capabilities to "measure" a lot of our PC hardware subsystems. If it is all OK the TMP chip release the
key for decrypting the LUKS partition, open up the encrypted partition and then boot our PC. If it instead detect Secure Boot
disabled, a UEFI BIOS firmware modification, a kernel or other .efi booting file modifications it stop the LUKS partition decryption
and stops the booting process.

This solution has been first implemented by "Clevis", a very cool piece of software, described in Appendix F of my tutorial at:
https://community.linuxmint.com/tutorial/view/2438.

It seems that also systemd has impemented a similar tool (from v. 249 and above) but at the moment it does not work for me.

Anyway this solution has a drawback. If you power on the PC and it is all OK it boot up without waiting for a pin or a password.

This is often inadvisable and it seem better to wait for a later solution, requesting at least a pin during the TPM start up process.

I hope I have better explained the layout and the functioning of my Linux FDE solution for PC with firmware UEFI using EFI STUB
boot loader.

Regards.

linux22

[lofi]

Hello linux22,

I read your preface, very nice, didn't know it was there. On a side note, I don't have a size problem with EFISTUB+objcopy efi files as I'm not dual booting.
I did notice that systemd boot documentation was spartan!
I didn't know you had spent so much time, including nights, to find a solution for everyone. Thanks a lot! Sure, FDE with GRUB would have felt more familiar for me, but
1) I didn't know it caused issues at every kernel update
2) When I saw that one of your tutorials allowed encryption of /boot itself I thought cool, that's the tutorial I'm picking! I have to say, when I was neither familiar with FDE *nor* GPT *nor* LUKS *nor* LVM *nor* EFI *nor* efistub *nor* objcopy *nor* signing files *nor* postupdate hooks (etc), typing all these commands felt pretty wild! (sweaty face emoji ) (at least in 2019, I saw you made lots of documentation improvements since). But I trusted you and it went smoothly, including updates, which was cool but also a bit magical (like wizardry).

Pros and cons :
- yes, I love the very fast booting!
- I don't think I have a TPM or TPM2 on my computer

Thanks again also for answering about the state of the art of latest linux installer FDE options. I mistakenly thought that officials distros had caught up, including Mint, after your pioneering work. I see it's moving, slowly, but moving...

>But you can not sign files that are not of binary type
I didn't know that.

And I didn't know about bad actors being able to flash the UEFI BIOS... Nice to see that here again you're working for a solution for everyone.
I understand that my configuration protects from the (classical) evil maid attack, I read about it a while ago and copied the files, but I have yet to flash it to USB to test it (for fun). I didn't even try to disable secure boot to verify that my Linux can't boot in our configuration (it feels enough for me when I saw that it wouldn't boot on systemd-boot when I forgot to sign it). I guess I'm not paranoid enough. Ain't it weird how I've dived into the details of your tutorial only because I wanted to change the kernel command-line options to get the verbose logs at boot? That's how I discovered that since 2019 you had implemented the "second last kernel" option with system-d boot as an improvement to your kernel update hook. That (the second last kernel) I really needed, and not just for fun.

TPM and Clevis : yes, seems quite nice, it's nice to know we have that as an option (for those who want to keep up with Windows 11 security policy... everyone is talking about TPM).

Actually I'm not adventurous at all, this was only my second linux install and my first Mint install. I find any OS install terrifying. But I wanted encryption. And I read a lot before I do anything. So I ended up reading that the traditional encrypted linux solution of encrypting only the /home folder was pretty lame. Unfortunately, when you start reading about security, the risks seem infinite. I can't remember what other security feature I wanted, but I dropped it when I learnt that (in 2019 at least) the classic linux install didn't even have secure boot, like windows. Which makes FDE a bit pointless. So that became my new main focus. And I wanted to ditch Ubuntu. And thanks to the magic of the web, I quickly found your tutorials!

I hope you have feedback on your Clevis TPM implementation. As for me, I'll probably not change anything until I get a new laptop!

Lastly : I thought I had found a small bug and the fix for it, was I wrong? (snipped and edit : yep I was wrong. I just double checked. For systemd-boot in /boot/efi/loader/entries I thought you had said to put "/EFI/Mint/kernel.efi.conf" in the file "mint.conf" instead of just "/EFI/Mint/kernel.efi" but you didn't. Not sure where I got this, sorry)

Thanks a lot for all the explanations, that's one of the things I appreciate in the linux community, we're not running a black box like Windows, we have the source code, the hardships, the stories, and the mutual help! For example when I research a new topic on wikipedia, I always go to the "history" section, I find it easier to understand the technical solutions when I understand the chain of problems they solved historically. So thanks for explaining your trials and errors and chain of thoughts. (btw I remember being happy to find maybe the most thorough documentation on all this here https://www.rodsbooks.com/efi-bootloaders/index.html but I lost interest when I was satisfied with the global picture and my issues were fixed. It's nice also when you... don't have to know about *all* the history!)

thanks for the very thorough reply,
take care,
lofi

[dobp]

Dear linux22,

After some time and a long experience of broken GRUB, I finally made the step towards systemd-boot following your as always very handy tutorials.
So this is about a dual-boot installation based on a previous setup on which I reinstalled only the Linux part. Given that I didn't want to spend time reinstalling Windows and that I got discouraged of moving Windows system partition to enlarge the ESP one (it is apparently likely to break the Windows install), I used the XBOOTLDR method you documented.

1. As a little variant, I installed Linux Mint 21 Cinnamon (it worked the same as in your tutorial without specific hassle) and used LVM for partitioning for which I simply replaced the last command of the step 3 of the Dual boot tutorial (sudo mkfs.ext4 /dev/mapper/sda6_crypt) by the following (given I wanted a 4go partition for swap, a 15go partition for home, and the remaining space for root, and specified all that in Ubiquity at step 4):

Code: Select all

sudo pvcreate /dev/mapper/sda6_crypt
sudo vgcreate mint /dev/mapper/sda6_crypt
sudo lvcreate -L 4G mint -n swap
sudo lvcreate -L 15G mint -n home
sudo lvcreate -l +100%FREE mint -n root

2. However due to the LVM partitionning, I got confused at step 5 by what should be the correct path to root partition to indicate in /boot/efistub/cmdline.txt. The correct answer is /dev/mapper/mint-root (with "mint" corresponding to virtual volume name and "root" to logical volume name, with a dash in between), and NOT /dev/mapper/sda6_crypt/mint-root as I thought it could be at first. Also, before rebooting at the end of step 5, I had used efibootmgr to change the boot order and put systemd bootloader first, meaning that after reboot I got trapped into a busybox terminal (due to the path mistake), without any option to boot to firmware and boot back to live USB (due to the boot order defined).
I eventually found my way out as I wrote down there (for reference, in that topic sda6_crypt is replaced by nvme0n1p7_crypt). It could be a set of commands to add to the first-aid kit appendix of your tutorial just in case.

3. What is more the version of systemd-boot currently shipped with Linux Mint 21 / Ubuntu 22.04 is 249.11. With that version I experienced an annoying issue - after booting to Windows, at next boot, the Linux entries (located on XBOOTLDR partitions) would disappear from the boot menu. After some investigation and thanks to a Github issue, I found out that that behaviour would happen only if Fast Boot was enabled in the BIOS (so in that case disabling Fast Boot is a good workaround). The issue may affect only installations on SSD, potentially due to the fact that given the higher data transfer speed, Fast Boot hasn't much to cut but the initialisation of some necessarry elements for XBOOTDRL partition to be recognised by the boot menu... A fix to that issue has been merged recently in systemd-boot master branch and I thought waiting for an Ubuntu package to come for this could be long, so I built systemd v252-rc1 from master.

Code: Select all

apt build-dep systemd
git clone https://github.com/systemd/systemd.git
cd systemd
meson -Dgnu-efi=true build  #the NO mentions do not matter as long as next command works
meson compile -C build systemd-boot bootctl

Once done, the built binary lays in /{path-to-git-folder}/systemd/build/src/boot/efi/systemd-bootx64.efi and should be used as a replacement for both /boot/efi/EFI/systemd/systemd-bootx64.efi and /boot/efi/EFI/Boot/bootx64.efi (and be signed with sbsign if we want to enable Secure Boot as described in your tutorial). With that systemd-boot version, Fast Boot can be re-enabled.

4. A first question to you - I read in the related Github issue that a systemd developper recommends different mountpoints for the ESP and XBOOTLDR partitions (ESP to /efi and XBOOTLDR to /boot) than those you indicate in your tutorial (ESP to /boot/efi and XBOOTLDR /boot/xbootldr) as a standard for better features compatibility, should it be only with the diagnosis tool bootctl.

You also should really mount your ESP to /efi and your xbootldr to /boot. And then use the build/bootctl from the above built step to list output as it has grown some better features to diagnose issues.

As taken in my bootctl output (this is shown only with the newer bootctl tool I can find in /{path-to-git-folder}/systemd/build/bootctl, not in the one currently shipped as an ubuntu package), it seems the bootloader cannot, potentially due to the non-standard mount points:

Code: Select all

   ✗ Picks up credentials from boot partition
   ✗ Picks up system extension images from boot partition
   ✗ Measures kernel+command line+sysexts

Was there a particular reason why you used other mount points, or could this be an improvement to bring to the tutorial ?

5. And another series of questions to you referring to TPM2 and the post in which you give some ideas of security levels. I was considering configuring clevis or systemd-cryptenroll but found the following warning on ArchLinux wiki:

Warning: If you use this method on your root volume, this means that, as long as the previously mentioned certain conditions are met, your computer will unlock automatically at boot without needing to enter an encryption password.

• This means that access to data is not protected in case the hardware gets stolen.

• Be aware that this method makes you more vulnerable to cold boot attacks, because even if your computer has been powered off for a long time (ensuring the memory is completely cleared), an attacker could simply turn it on and wait for the TPM to load the key automatically. This may be a concern for high-value targets.

A. Reading so, I understand that OK, TPM enables checking nothing was tampered with and releasing the key for disk access only after so. But then the computer goes until OS login screen (if activated) with unlocked disk without any password being entered so far. Meaning that at this moment, your data fully relies on OS protection rather than on the encryption lock when password has to be manually entered. Therefore I am not very clear between your levels 4 and 5 and I wonder whether TPM is a real addition in terms of security over FDE + Secure-Boot with a solid encryption password (say over 128bits of entropy) ?
B. Also do you have an opinion on the use of clevis over systemd-cryptenroll (although the linked tutorial does not seem compatible with Debian/Ubuntu/Linux Mint default's initramfs-tools) or tpm2-tools ? Or is clevis maybe just the easiest one to work with ?

6. Overall, I find systemd-boot simple and nice and look forward to finding it more resilient than Grub. Only thing I kind of regret is the fact that LUKS password is asked after selecting XBOOTLDR entries in the boot menu, instead of before displaying the boot menu as it used to be with the Grub setup which was giving a better "security user experience" with a bit of additional obscurity, although technically at least as secure I presume.

Thanks again for following this topic and sharing your findings,
Best regards,
dobp

[linux22]

Hello dobp, sorry, I know I am late but in this period I am busy at work. I think I will be ready to answer your questions at last within the end of november.

Anyway I can anticipate a quick response to your questions concerning TPM with clevis or systemd-cryptenroll.

YES, I think unlocking the FDE partition without a PIN is quite dangerous and I do not like it.

I have experimented the FDE unlock via TPM with clevis and it seems working very well, but I do not undestand how configure the process with a PIN.

So my configuration, at the moment, simply unlock the FDE at power up.

You know that Windows Bitlocker already has the option to configure FDE unlock via TPM with PCR registers + PIN.

At the moment I have not yet experimented the systemd-cryptenroll method (my systemd is too old) but it seems that with systemd version => 251 it will be possible configure the unlocking of FDE via TPM with PCR registers + PIN (see https://wiki.archlinux.org/title/Truste ... orm_Module at § 2.2.1 "Note: As of systemd 251 it is now possible to require a PIN to be entered in addition to the TPM state being correct. Simply add the option --tpm2-with-pin=yes to the command above and enter the PIN when prompted.").

When this solution will be available (I think within 2 years, after release of Debian 12 Bookworm -> Ubuntu 24.04 -> Mint 22) we will be able to configure FDE unlocking via TPM with PCR registers + PIN, like Windows Bitlocker.

Regards.

linux22

[lofi]

SUBJECT : dist-upgrade years after following one of these awesome tutorials (secure boot). Has anyone here tried a dist-upgrade years after they setup their Mint with secure boot ? How did it go ?

Hi everyone, hi linux22,
I know from last message that linux22 is quite busy right now, I'm glad if anyone else can answer!

To linux22,
I don't know if you remember me from above, I'm lofi, who one day decided I wanted verbose boot, and achieved it after I realized I needed a much better understanding of your update hook script (unified EFI bootloader, sbsign, objcopy...). Thanks again for having clarified a few points.

DIST-UPGRADE : I have ctrl+F "upgrade" the 5 pages of this topic and found nothing related to dist-upgrade. I have recently moved from Mint 19.1 to Mint 19.3 and everything went smoothly. But the upstream for Mint 19.3 is still Ubuntu 18.04, and it is soon reaching EOL. So I have to do the big jump, a "real" (bigger) dist-upgrade.
I have tried to gather the most available information myself because I know your time is precious, but the months are passing, and I'm more and more confused...
So please bear with these questions,

Intro : I can't find the exact tutorial of yours that I have followed. It was probably one which is 404 now. What I did was a tutorial to install linux Mint 19, with full disk encryption (including /boot), GPT, secure boot (but no LVM).
Questions :
- I'd like to prepare for anything that could go wrong by understanding what I have done 3 years ago. But I was not able to find the command where we encrypt /boot/efi. I saw the cryptsetup command to encrypt / aka /dev/mapper/sda2_crypt. But /boot/efi is on sda1...

Here is my lsblk :
sda ____________ 8:0 _ 0 __ 238,5G 0 disk
├─sda1_________ 8:1 _ 0______ 1G 0 part /boot/efi
└─sda2 _________8:2 _ 0 _ 213,6G 0 part
└─sda2_crypt __253:0 _ 0 __213,6G 0 crypt /

What I was wondering was : where are the keys to decrypt /boot/efi ? I searched a lot, I couldn't find. I ended up reading the tutorial I thought I had followed in its entirety, I thought maybe /boot/efi was encrypted at the end? I didn't find that. And that's when I realized the actual exact tutorial I followed 3 years ago was nowhere to be found.
If you don't have time to explain, what command could I type to prove that /boot/efi is encrypted ?
But this is not my main worry for dist-upgrade.

- You have updated your (awesome!) tutorials several times, so I get hints of what will be different when I move on to Mint 20. For example, on Mint 19, vmlinuz is a symlink in / (on my machine it says "broken link", but 'readlink' can find the target, I don't understand why). On Mint 20, it's in /boot. But maybe I'm confused because I use the unified EFI bootloader ?
Anyway : when should I update the update hook script to the new version ? Before starting the dist-upgrade ? After ?

- Is it the only hurdle I will encounter in the dist-upgrade ?

- I see many people saying that a Mint dist-upgrade is so complex and risky (even without FDE nor secure boot) that one might as well do a fresh install. But I don't have a /home partition, and a "fresh install" seems absurd to me, knowing how many things in the home folder's hidden files depend on specific versions of programs... I suppose, and hope that Mint dist-upgrade tools do wizardy so that everything moves on smoothly to new versions. This is why I won't do a fresh install. But if you recommend it instead of dist-upgrade, I will listen.

- I don't even know where to find documentation about the tools that the Linux Mint team have built for dist-upgrade. - edit : https://github.com/linuxmint/mintupgrade

- I think we have to modify /etc/upstream-release/lsb-release with the new Ubuntu upstream version. Is it true or does the Mint dist-upgrade tool do it itself ? If not, when should we change this file ?

Of course I'm doing backups (Timeshift + Mintbackup) but I read bad stories about timeshift and dist-upgrades... (someone tried to roll back to previous Mint version, but he ended up stuck inbetween, and he didn't even have secure boot!)
Btw my secure boot config is an "old" one, I think what we were doing is "self-signing", no TPM, nothing.
Is there somewhere where you gave advice about dist-upgrade ?
If not, I hope you can help by the end of November, and if not, before Ubuntu 18.04 EOL ! (April 2023)

thanks, and thanks for all the work you shared on securing Linux Mint!
--
lofi

[lofi]

(dist-upgrade a Unified EFI bootloader system : replying to myself while waiting for an answer)
Please tell me if I should move this to a separate topic

Well, my brain was fried yesterday (message above) because I was sure I had LVM and couldn't find any logical volume, also because I didn't manage to find if my /boot/efi is encrypted. Today I realized I had not properly searched the web for the other, most important things.

- Why upgrade instead of clean install ? viewtopic.php?t=253988 (follow-up to my questions above)
(See below)

- Clean install : does it overwrite all partitions ? viewtopic.php?t=378654
Comrades don't really give a clear answer ("you tell the installer yes or no"). But I think the answer is yes (unless you want to install the OS somewhere else). That's why people do a "hack" (it's not standard, and one comrade says it's not that easy) to have a separate /home partition. Clean install will wreck absolutely everything on your system partition, but not the whole disk. (for a moment I hoped it was like Windows : apparently you can install a new version over an old one and what is really happening behind the scenes is an upgrade, not erasing your config)

(now I'm very surprised nobody is saying "hey, what you need for a clean install and then re-do your whole setup from scratch, is this : (apt command to backup all the list of packages you had installed)" and tips like this...)

- Linux Mint blog, how to upgrade to Linux Mint 20 (I had read this many times, but this time I found it (again) through a web search for "secure boot") https://blog.linuxmint.com/?p=3946 => search hits in the comments.
=> Apparently disabling secure boot (in BIOS I guess) before using the dist-upgrade tool helps.
=> Clem himself replied about dist-upgrade and secure boot. He said (to someone stuck in the update process gone wrong) : disable secure boot ("especially if you don't know why you have it"), and he says to roll back to Mint 19 with Timeshift (which I read somewhere else can end up in user being stuck between two Mint versions...)

So basically what I still need here in this specific thread, is to find out if disabling secure boot in BIOS is enough to let the dist-upgrade tool run smoothly. And if not, when should we change the update hook script and the /etc/upstream-release/lsb-release file ? And is there other specific things to do ?
(please tell me if this would belong more to a new thread "dist-upgrade and secure boot")

thanks all!

[dobp]

Hello linux22,

No worry take all needed time, nothing really urgent here for me.
Got your point about the work in progress regarding TPM+PIN waiting for a systemd upgrade.
Just being curious at this point - do you have any idea on whether PIN mentionned in Archlinux's TPM help page refers to LUKS password or a specific PIN to set up?

Hello lofi,

My understanding is that /boot/efi is not actually encrypted (as shown in your lsblk, you should be able to see the content of your sda1 partition from within a live USB system for instance - you may want to doublecheck that). It is however secured, in a different way - the only binary that could execute at boot is the one self-signed that SecureBoot (if enabled) will allow. So provided that SecureBoot is enabled and that access to your Firwmare bootloader is protected by a password, there is no straightforward way to boot your machine for an intruder without your LUKS password. Remains the option of tampering firmware files to circumvent SecureBoot (I nevertheless assume this not straightforward) which you will not know about except if you enabled TPM.
The script made by linux22 generate a new unified kernel files everytime kernel files are updated. If the mint upgrade process was to break the script and/or cause your OS not to boot anymore you should still be able to boot on a Live USB key, mount your boot partition, and set up the script again (see. Appendices A and B of the latest tutorial version - Linux Mint 20.X and 19.X with Full Disk Encryption, directory /boot included version 1.4)

So basically the main things before upgrading would be to ensure having all required backups just in case (timeshift + home folder + list of installed softwares), disabling SecureBoot, and having a LM 19.3 Live USB ready so that in case of failure you could still do a fresh LM 19.3 installation and restore all your backups OR better, mount to your LM 20 or 21 upgraded partition and sort a potential issue preventing it from booting. You also need to secure a bit of free time ahead and a way to access the forum in case of trouble...
That being said, I was also threatened by LM 19.3 EOL and decided to shift to LM 21 with a clean install (by the way the FDE tutorial of linux22 worked well with LM 21). Restoring everything manually as I did was time consuming, but the clean install (or was it only due to the version upgrade?) solved other issues I had with LM 19.3 and it was an occasion to sort my mess and remove unused pieces of software.

That doesn't relates to this thread anymore, but FYI clean install does not necessarily overwrite all partitions (it only means to overwrite the root partition). However in your case, as you have only one common partition for root and home data, everything will indeed get overwritten it. It is very easy to set up a home partition, however after OS upgrade you might still encounter issues due to broken software not compatible with newer version of the libraries shipped with the new OS version for instance.

[lofi]

Hi dobp!
What a pleasant reply.

My understanding is that /boot/efi is not actually encrypted [...] It is however secured, in a different way - the only binary that could execute at boot is the one self-signed that SecureBoot (if enabled) will allow.

Thanks a lot for clarifying. Before thinking of dist-upgrade, I wanted to understand the "topology" of my partitions, I almost became mad searching for my logical volumes (I didn't remember deciding against this). Doubts about /boot/efi encryption were the cherry on the cake.
Yes, my firmware bootloader is password protected.

Remains the option of tampering firmware files to circumvent SecureBoot [unless TPM]

WelI I heard about this, for now I feel good with my level of security. It was just that question of /boot/efi encryption, that suddenly cast a shadow of doubt on all the chain, you reassured me.

The script made by linux22 generate a new unified kernel files everytime kernel files are updated.

Yes, this I know, I even edited it a bit, as I wanted verbose boot like I used to have on my old Buntu (small security risk, but I find it very cool, the text moves so fast on the screen!). When I realized that with secure boot, that would be much more work that just one Google copy/paste, I started studying linux22's update hook closely (long time ago, but I remember learning about objcopy and object files). Unfortunately, I can never give up!

having a LM 19.3 Live USB ready

Ok. Precious advice. I feel more confident now. I'm an overthinker, almost OCD level, and I'm surprised people are not aware that an OS is millions of lines of code, so during a dist-upgrade, there are a few things that might go wrong (with or without secure boot).

and decided to shift to LM 21 with a clean install

Well, at this point, with all the info including your input, maybe that's what I'm going to do. My Mint 19.3 doesn't really have problems, but I know it's bloated with all I installed and don't use. I thought I'd upgrade to 20, then to 21... which is double the work, and the risk (of course it's not the end of the world if I have backups).

It is very easy to set up a home partition

ok, I remember repeating here what I heard elsewhere, that it was hard. Of course it depends on our level. That sentence was probably addressed to a beginner, of course here we are in the Chad thread! Can't be that hard!

I remember being pretty impressed with your question to linux22, a couple weeks ago. It's so nice you answered all my questions. Unfortunately, I can't answer yours! Good luck with TPM!

thanks
lofi