Liveslak 1.8.2 re-adds Secure Boot support

When Slackware-current upgraded the Grub package to 2.12,  liveslak lost the ability to boot on a computer with Secure Boot enabled.

Grub 2.12 is a lot stricter than the previous 2.06 release when it comes to trusting the files it loads and executes. The way it works now is as follows (step 1 and 2 are unchanged):

1. The Secure Boot computer will only load the primary bootloader when that has been signed with a SSL certificate which is stored in NVRAM (the Database key). Unless you have deleted the original Db, the Dbx, the KEK and the Platform Key in order to install your own self-generated keys, this will be a Microsoft certificate.
   Linux distributions nowadays mostly use a UEFI bootloader called “shim” for Secure Boot. The bigger distros have one in their repository which has been signed by Microsoft. Because this Microsoft certificate is already stored in your computer’s NVRAM, the “shim” trusts it and proceeds with booting.
   Slackware does not have a “shim” which is signed by Microsoft, and nor do I. For liveslak I simply re-use one of the signed “shim” packages from either Fedora, OpenSuSE or else Debian.
2. The “shim” bootloader will only load a secondary bootloader (Grub for example) if it recognizes and trusts the SSL certificate with which that one has been signed.
   The big distros have embedded their own certificate inside their Microsoft-signed “shim” and for that reason, the “shim” implicitly trusts the distro certificate. This “shim” will then accept and load any secondary bootloader which has been signed by that same distro certificate. It allows a distro to have a transparent boot process (Secure Boot or normal boot) without any specific user actions that need to be performed.
   In our case since I signed our Slackware Grub bootloader with my own SSL key and certificate, the “shim” must be taught to accept this certificate as trustworthy. We do this by enrolling the certificate into the MOK – another piece of storage space in the Secure Boot computer’s NVRAM. MOK stands for Machine Owner Key… and you are the Machine Owner. Since you have to be physically present at your computer when you tell the MOK-manager to enroll the liveslak SSL certificate, that makes the certificate trusted.
   How that is done? I wrote an article about that, three years ago: Secure Boot support landed in liveslak 1.5.0 and I invite you to re-read it.
   The “shim” will load our liveslak Grub bootloader after you enrolled the “liveslak.der” certificate in the MOK.
3. Now it gets “interesting”. Grub 2.06 would happily continue loading the kernel, the initrd and then boot Slackware Live. But Grub 2.12 requires that every file it loads when Secure Boot is enabled, must be signed by a private GPG key for which Grub stores a copy of its public key. Ehh?

I called that new requirement for the boot process “interesting” but actually it was something to tear your hear out over. Debugging the boot of a computer before the stage where the Linux kernel takes over from the bootloader, is extremely difficult.
I had a good look at the Grub documentation and my liveslak sources back in July and August and actually did most of the changes that were needed during that time.

Most of the work back then went into a big rewrite of the iso2usb.sh script. When Grub needs to check a GPG signature for every file it loads from disk, the initrd must be GPG-signed as well. That means, iso2usb.sh is no longer allowed to un-pack, update and re-pack the initrd image file because that will invalidate the GPG signature.
What I did was: re-use the logic that was already implemented in isocomp.sh, a companion script to enable persistence for the Live ISO when that is used on a Ventoy USB disk.
From now on, all customizations of your Live USB stick are stored in the file ‘/liveslak/slackware_os.cfg‘ in the Linux partition. The initrd remains unchanged.

You need to use the latest version of iso2usb.sh though! Delete older versions please. They are incompatible with the new liveslak.

When that rewrite was finished, I needed to find out what the requirements were for the GPG signing process and I needed to find a way to actually use a GPG private key in my scripts without exposing Alien’s own GPG keys. I learned about ephemeral GPG keys: the liveslak ‘make_slackware_live.sh‘ script creates a GPG private/public key pair, does all the signing, stores copies of the GPG public key inside the Grub bootloader image and on the EFI partition, and then erases the private key (it will no longer be used).
Alas, even with all the requirements apparently having been satisfied I kept running into “security violation” messages on boot.

In August, I simply gave up trying to fix this, because it was so frustrating and also because real-life was too demanding.
But during the Christmas holiday, after I had completed much of my AFFiNE cloud server article, I decided to give it another shot. Actually, I had intended to work on a ‘reboot’ of the Live DAW project but the feedback I am getting on my recent blog post is luke-warm and it did not inspire the confidence that more than a few people would actually use a refreshed DAW environment. Not to worry – that DAW refresh is still on my TODO list.
Looking at the liveslak code with a fresh perspective was really helpful and I managed to deal with the missing pieces. The final hurdle was taken when I realized that I needed to update the SBAT file which gets embedded into the Grub boot image, precisely because I am now using a newer Grub version. As I said, hair-tearing.
With good results: the liveslak-1.8.2 is again supporting Secure Boot.

Note: Secure Boot is supported only on 64-bit computers and only after you transferred the ISO Live content to a USB stick using the iso2usb.sh script.

Anything else that’s new?

Most of what happened between releases 1.8.1 and 1.8.2 is small stuff, a lot of these small changes were necessitated by the evolution of Slackware-current and to keep the Live ISOs working.

One thing worth mentioning is this. The liveslak scripts changed a lot internally, but their usage is un-changed  with a single exception. The “-w” or “–wait” parameter to the “iso2usb.sh” script has been removed. It was meant for slow USB sticks where it takes more time for the USB subsystem to settle in the kernel. Using this parameter allowed you to increase the wait time for your USB stick to boot into the Operating System. But I solved that by using a loop in the live init, and the script parameter is no longer needed.

Download Slackware Live Edition

You can find a set of new ISOs based on liveslak on download.liveslak.org/latest/, the 64bit versions of them support Secure Boot.

It will probably work best if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick, it will give you a persistent environment with optional data encryption and this will allow it to boot on a lot more computers.
Alternatively, create a Ventoy disk and copy the un-changed ISO on it. You can then use liveslak’s ISO companion script ‘isocomp.sh‘ to add data persistence for that ISO on the Ventoy disk.

Get liveslak sources

The liveslak project is hosted in git. Its browsable cgit interface is here: https://git.liveslak.org/liveslak/

A set of the liveslak scripts can also be downloaded from http://www.slackware.com/~alien/liveslak/ or https://slackware.nl/people/alien/liveslak/

The liveslak public key (SSL certificate in DER encoding) that you need to enroll can be downloaded from https://download.liveslak.org/secureboot/liveslak.der

Let me know your experiences!
Cheers, Eric