Secure Boot ???
Secure Boot is part of the UEFI specification and first appeared in the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification (Errata C). It is meant to prevent the execution of unauthorized code upon boot of a computer. Most modern Personal Computers will have a way of enabling Secure Boot in UEFI, but it is common to leave it disabled if you are not running a Microsoft OS on it since Microsoft controls Secure Boot.
For dual-boot scenario’s the story is different however. Microsoft Windows 8 and 10 advise to have Secure Boot enabled but don’t enforce it, but as far as I know, for Microsoft Windows 11 enabling Secure Boot will be a requirement to get full upgrade support.
Microsoft’s own Windows OS-es fully support Secure Boot (naturally), but non-Microsoft Operating Systems that want to boot on a Secure Boot enabled computer, must have an initial bootloader which has been cryptographically signed with the ‘Microsoft UEFI CA‘ key. Getting Microsoft to sign a 3rd-party (mostly Linux) bootloader is a complex procedure which involves money (but not always) and establishment of trust. You need to realize that if a malicious bootloader gets accidentally signed by Microsoft, this bootloader could be used to deliver all kinds of nasty to every Secure Boot platform in existence. And that would defy the whole purpose of a tightly controlled ‘Secure Boot‘ environment.
It’s likely that more and more computers with MS Windows installed or with a dual-boot configuration will have Secure Boot enabled in the near future. For Slackware and its derivatives, including my liveslak based ISOs, this is a potential problem because Secure Boot is not supported yet and therefore our OS will not launch.
Additionally, one of the use-cases of liveslak ISOs is to take it along with you on a USB stick on your key-chain and boot random PC hardware with it – just for fun, or to test the Slackware compatibility of new hardware, or simply to have your Slackware desktop with you on a stick all the time.
A liveslak ISO will be a lot less useful if every PC you encounter has Secure Boot enabled.
So I set out to find a solution.
One possible way out of this dilemma is to acquire a Microsoft-signed first-stage bootloader, just like Red Hat, Fedora, Debian, Ubuntu and the other big brothers already provide. Like said before – this process is complex and I am not able to satisfy the requirements at the moment. In future, who knows? I am working on that.
Alternatively, and other small distros seem to do this too, an already signed bootloader can be ‘borrowed’ from another distro and used to boot a liveslak ISO. But that has consequences which I will elaborate further down. This is the solution I chose.
Note: In case you have doubts: the liveslak ISOs support Secure Boot from now on. But nothing changes when your computer does not have Secure Boot enabled. Slackware Live Edition will boot and work exactly like before.
Boot sequence
Let me give a quick and dirty and possibly not 100% terminology-accurate explanation of the boot procedure in a Secure Boot computer.
- The TPM chip in the computer may be used to store a bunch of (Microsoft) security certificates which are trusted by the Secure Boot subsystem of UEFI, as well as (potentially) a list of certificates that have been revoked due to security violations. Otherwise these keys are stored in NVRAM (non-volatile RAM).
Secure Boot will load only bootloaders that have been signed by a trusted Microsoft certificate. The most widely used Linux bootloader which Microsoft accepts for signing is the ‘shim‘, a trivial application which does not do much more than verifying the signatures of the second-stage bootloader which it is hard-coded to look for. A signed ‘shim’ binary also contains an embedded SSL certificate of the distro that owns the shim binary.
The shim accepts two certificates when it checks the signature of the second-stage bootloader and other binaries: one is the Microsoft certificate and the other is this embedded distro certificate. This allows such a distro to provide a nice unattended problem-free boot on every computer with Secure Boot enabled. - The shim loads the second-stage bootloader, this is most often the Grub2 bootloader but it could be any EFI image file (such as rEFInd). The hard-coded default filename that the shim will attempt to load is ‘grubx64.efi’ so whatever your distro bootloader, it needs to be renamed to that.
Shim will check the signing certificate of that file and will proceed only if it recognizes the certificate as valid. - Grub will be informed by the shim that it loads in a Secure Boot environment and because of that, Grub will ask the shim if it is OK to load the kernel it is configured for. Shim will check the signing certificate of your kernel and will signal an ‘OK’ to Grub only if it recognizes the kernel’s signing certificate as valid.
- Your Linux OS will now boot properly.
But what happens if Grub or the kernel are not signed, or when they are signed with an un-recognized certificate? Well, your computer will refuse to boot.
Lack of trust
The problem for liveslak (and for Slackware) is that neither Patrick nor I own any of the private keys corresponding to the SSL certificate that these big distros embed in the signed ‘shim’ binary they provide (naturally). Therefore I must sign the liveslak grub and kernel images using my own private key and public certificate pair.
The public certificate I use for signing is not recognized by UEFI SecureBoot, since it is not embedded in any bootloader which has been signed by the Microsoft Certificate Authority. If Secure Boot is enabled then the signing certificate of liveslak’s grub and kernel images will not be accepted by shim… and the Live OS fails to boot.
As the owner of your PC, you can clear the Microsoft certificates from the local certificate store and load your own certificate instead. Your computer will then boot without issue because your bootloader finds the certificate that it is validating in the trust store.
This is probably the best solution if you are never going to run MS Windows on it anyway. But if you do, or might, or if you want to provide a solution that works on a multitude of computers besides your own, you need to come up with something else.
You are the Machine Owner
Lucky for us poor distro developers, Secure Boot recognizes a database of Machine Owner Keys (MOK) next to the Microsoft trusted keys. And you are the Machine Owner if you have physical access to the computer and know the password to unlock the MOK database (it is empty by default).
The MOK can be populated with public keys of your own making, or of your friends… and/or with liveslak’s public key. And then the shim will accept liveslak’s signed Grub and kernel… and liveslak will boot just fine.
Managing Machine Owner Keys (MOK)
My repository contains two relevant packages: mokutil and sbsigntools. The mokutil package contains the ‘mokutil’ program which allows you to query the SecureBoot NVRAM and to manipulate MOK certificates (the latter only if Secure Boot is enabled). The sbsigntools package contains ‘sbsign’ which is used by liveslak to cryptographically sign the Grub and kernel images.
To check whether Secure Boot is enabled, run:
# mokutil --sb-state
If this returns “Secure Boot enabled” then you are probably running a commercial Linux distro :-). In this case, you can generate a MOK enroll request to the shim before rebooting:
# wget https://download.liveslak.org/secureboot/liveslak.der # mokutil --import liveslak.der
You will be prompted for an optional password. If you enter one, this password then needs to be entered again after reboot to complete the MOK enrollment.
If Secure Boot is not enabled, don’t worry: you can still enroll this ‘liveslak.der’. Just continue reading.
Adding liveslak.der certificate to MOK database
The remainder of the article will describe in detail how to add the liveslak public key (a SSL certificate) to the MOK if you were unable to use the mokutil program as described above.
Note that adding the certificate is a one-time action. Once the MOK database contains the liveslak certificate, future liveslak ISOs will boot on your SecureBoot-enabled computer out of the box.
Enable Secure Boot in your UEFI (press F1 or whatever key your computer needs to enter setup and find the proper menu to enable SB). Then reboot your computer with a liveslak (1.5.0 or later release) medium inserted.
UEFI will look for the first-stage bootloader on the liveslak medium in the ESP partition (ESP = EFI System Partition which is a FAT partition with partition type 0xEF00). According to UEFI spec, it wants to load the file ‘/EFI/BOOT/bootx64.efi’. The Fedora ‘shim’ binary which is now contained in the liveslak ISO has been renamed to that exact filename. Shim loads, it will try to load our Grub and discovers that its SSL signature is invalid/unknown. Shim will then ask you if it should load the MokManager instead (the ‘mmmx64.efi file in the same directory) which is signed with the distro certificate embedded in the shim.
If you press ‘any key’ within 10 seconds, the MokManager will load and you will have your opportunity to enroll the ‘liveslak.der’ certificate. If you wait instead, the computer reboots and if you had already made an enrollment request as described in the previous paragraph, that request will then be erased and you’ll have to try again.
If MokManager loads, it will show the below screen if you created an enrollment request before the reboot. Select the “Enroll MOK” to complete that enrollment request.
If you entered a password during the “mokutil –import” command you will have to enter that same password next:
If you did not create an enrollment request prior to reboot, then this particular menu item will not be present and you should use the “Enroll key from disk” menu instead.
A simple and spartan file browser will be your guide towards the ‘/EFI/BOOT/’ directory on the liveslak medium; select ‘liveslak.der’ file and confirm.
After enrollment of the ‘liveslak.der’ certificate, you must reboot.
After the reboot, your Slackware Live Edition should boot as usual. If you watch closely you will see a flash right before Grub loads – that is the shim loading right before it.
Now, you can check that Secure Boot is actually enabled:
root@darkstar:~# dmesg |grep -i secure [ 0.016864] Secure boot enabled
Cool!
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.
I tried also generating 32bit ISOs but they refuse to load the init script. The kernel loads, it unpacks the initrd image, but then the boot process stalls right before control is handed over to the initrd. I have no idea why. I tried generating ISOs with an older release of liveslak (1.4.0) that had proven to produce working 32bit ISOs but no luck. Something in the new 5.15 kernel perhaps which liveslak fails to add to the ISO? Suggestions are welcome.
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 apparently this will allow it to boot on a lot more computers.
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
If we don’t use secure boot, will it still work as usual?
Certainly! On a computer without Secure Boot, the liveslak ISOs will work as usual, nothing has to be modified or disabled.
Gotcha. It’s good that this is an option for the future, and for those who do need to dual-boot.
FWIW, I am a dual booter who recently upgraded to win11. I have the TPM chip enabled but secure boot disabled and boot in UEFI mode. win11 has no issues with this and I am continuing to get updates from microsoft.
Hi Eric.
Necessary!. Thanks for thinking in users like me having a USB stick with liveslak in my wallet.
Best Regards.
Francisco.
I see you’ve been hard at work! I started using PreLoader.efi / Hashtool.efi to get my Liveslak usb past Secure Boot at work. I was responsible for refurbishing / imaging corporate class laptops and high end workstations, majority running
Windows, of course, but there were the occasional RHEL machines. It’s amazing how many times I used that usb to bring a stubborn unit back from the dead. I said it on LQ, AlienBob made me look like a genius! Liveslak in the efivars, and I was just getting ready to update my trusty Liveslak. Perfect timing. You are the man!
normally with certificates they have an expiry date. is this the case with signed uefi shim/loaders? ie. will the machine stop booting after 3yrs or something?
The liveslak.der certificate is valid for the next 5 years:
$ openssl x509 -noout -in liveslak.der -inform der -enddate
notAfter=Nov 2 23:59:59 2026 GMT
In five years, we’ll see what happens. Before that time, if I am still active, I will have updated the certificate I use to sign the bootloader/kernel. If I have disappeared, you need to re-sign the grub and kernel images yourself and enroll the new certificate you used for that.
hi hope you are are around for many more years to come 🙂
Thanks for your very clear explanations re secure boot.
I see that an EFI partition is required, presumably populated with specifics.
I have an HP 6300 with a completely blank disk, and I have been wondering how to create such a partition. (Naturally, I reject the idea of installing Windows to get that partition!!)
John
The EFI partition is required anyway if your computer is of the UEFI type (as opposite to BIOS).
So even if you won’t enable SecureBoot, you still have to create a (v)FAT partition with partition type EF (or ‘0xef00’ in gdisk). It will get mounted under /boot/efi/ in Slackware and other distros and it’s where UEFI boot files are installed.
See for instance https://docs.slackware.com/howtos:slackware_admin:installing_on_uefi_hardware#creating_your_own_install_media_for_older_slackware_releases
Congratulate Eric!
Exceptional work.
I’ve managed to secure boot with this liveslack on a HP notebook.
I had do disable some HP security crap in BIOS and boot UEFI without secure boot.
mokutil –sb-state was:
secureBoot disabled
Platform is in Setup Mode
Then I tried to import liveslak.der by HP BIOS, with complaining about missing PK.bin ,KEK.bin, DB.bin and DBX.bin.
So for curiosity I fired “mokutil –import liveslak.der”
On my surprise the command finished successfully regardless secureboot was disabled.
After reboot I followed upper instructions and finished with secureboot liveslack.
I have a few questions:
Regarding writing in https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
for linux secureboot all executables involved in a boot process must be signed (grub, kernel, modules..)
sbsign is in your ISO, so what have to be signed with certificate and how to do that with huge amount of kernel modules files?
As secureboot is a future standard, lilo boot manager will be replaced with grub in a near future in a Slackware? Or elilo is OK?
Best regards.
Zdenko, I have no idea about how Slackware will deal with Secure Boot in future. All the work to add Seure Boot support to liveslak is contained in a single git commit (https://git.liveslak.org/liveslak/commit/?id=f5a3e197512428a14925376345215fcc79f73c8b) which should help others in getting to grips with the modifications that are required.
Lilo does not work on an UEFI computer anyway, so this is not relevant to the discussion. And elilo does not support SecureBoot at all, it will happily boot anything you tell it to. Which of course means that you can still use elilo instead of grub in a SecureBoot scenario, it will just not add any kind of security.
Coming back to your other remark: everything needs to be signed which is loaded through shim and grub, but there are shades of grey here. The grub image used in liveslak is a standalone image which includes all grub modules we need, and the grub image is therefore the only one that needs signing. If you used a grub loader which calls modules from disk, then all these modules need to be signed as well.
The kernel must be signed but for liveslak, the kernel modules do not need to be signed.
You can however ‘harden’ the grub configuration with additional signing requirements. For that, you add a public GPG key (not a SSL key) and configure grub to check everything it loads for the existence of a GPG signature. I.e. the kernel plus all kernel modules need to be signed with your private GPG key. For me that is a step too far and not manageable.
Thanks for the explanation.
SB is so complicated. Hope that HW manufacturers will build it in a FW as an option, as is now for a long time.
Sorry if this is “solved” elsewhere, but it’s directly related to slackware live usage…
Recently used a Slackware Live usb to install Slackware to a new laptop. Not this secureboot release, but the previous release x64-current. Used setup2hd without issue then as per the instructions I used unsquashfs commands to install the alien, alienrest and multilib modules to the new installation. After boot up and some normal configuration I went to update via slackpkg (with slackpkg+ already installed) and ended up with this message:
root@milliways:/etc/slackpkg# slackpkg upgrade-all
Checking local integrity… DONE
You have a broken /var/log/packages/ – with multiple versions of the
same package.
The list of packages duplicated in your machine is shown below:
aaa_glibc-solibs-2.33-x86_64-4
aaa_glibc-solibs-2.33_multilib-x86_64-4alien
ffmpeg-4.4-x86_64-1
ffmpeg-4.4-x86_64-2
ffmpeg-4.4-x86_64-1alien
freerdp-20160810-x86_64-1alien
freerdp-2.4.1-x86_64-1
gcc-11.2.0-x86_64-2
gcc-11.2.0_multilib-x86_64-2alien
gcc-g++-11.2.0_multilib-x86_64-2alien
gcc-g++-11.2.0-x86_64-2
gcc-gfortran-11.2.0_multilib-x86_64-2alien
gcc-gfortran-11.2.0-x86_64-2
gcc-gnat-11.2.0_multilib-x86_64-2alien
gcc-gnat-11.2.0-x86_64-2
gcc-go-11.2.0-x86_64-2
gcc-go-11.2.0_multilib-x86_64-2alien
gcc-objc-11.2.0-x86_64-2
gcc-objc-11.2.0_multilib-x86_64-2alien
glibc-2.33-x86_64-4
glibc-2.33_multilib-x86_64-4alien
glibc-i18n-2.33_multilib-x86_64-4alien
glibc-i18n-2.33-x86_64-4
glibc-profile-2.33-x86_64-4
glibc-profile-2.33_multilib-x86_64-4alien
You can (R)emove one or more of, or (I)gnore these packages.
Select your action (R/I):
I ran into this same issue with a previous Slackware Live to HDD installation on another laptop. On that one I removed some packages, broke my setup, rescued and fixed it. Now, before attempting the same, I figured I should 1) ask for the correct solution and 2) inquire as to the source of the issue and possible ways to prevent it from happening in future installs.
The solution is not to use unsquashfs to install the content of those .sxz modules. These alien, alienrest and multilib modules contain packages that *replace* Slackware packages when merged in the overlay of liveslak, but if you install Slackware to hard disk and afterwards unpack the *.sxz modules on top, the Slackware packages do not get replaced but the liveslak packages are *added* … leading to all kinds of duplicates and the above errors.
There would not be an issue with *.sxz modules which contain unique packages, such as the nvidia or daw modules.
The best solution is to create a persistent USB stick, add all these modules to the /liveslak/addons subdirectory, boot that stick and then run setup2hd. Then the whole bunch will get properly installed.
hmm, ok. I see where the error occurred on my part.
I did have those modules on the usb in the addons subdir from which setup2hd was run. I think the problem came from the misinterpretation of a message during the install/setup telling me x out of y modules were installed and that I can install any additional modules by running unsquashfs …
Maybe I just used to Slackware requiring manual intervention because I took this message to mean that I needed to manually install those modules from addons when, in hindsight, it seems the modules that weren’t installed were from somewhere else (possibly extra)? Perhaps a minor update to the message in your install dialog script for clarity?
Anyway, is there a good (correct) way to resolve the issue on a running system or should I just wipe everything and reinstall?
Thank you Eric !
I am studying my new Laptop which came with Win11 Home.
Like downhomechunk, my Laptop came with TPM Enabled but Secure Boot Disabled.
I’ve have been able to upgrade Win 11 several times over the past week, but I wonder how long that will last ?
I’ve been running Slackware Live Edition 01-nov-2021: 1.4.0.2 but I downloaded and installed 01-nov-2021: 1.4.0.2 and sbsigntools-0.9.4-x86_64-1alien.txz
For the record,
[code]
# mokutil –sb-state
SecureBoot disabled
Platform is in Setup Mode
[/code]
Any idea what ‘Setup Mode’ is ???
I found this link
https://docs.microsoft.com/en-us/answers/questions/358185/secure-boot-key-management.html
but no real answers.
Anyhow, BIG THANKS
— kjh
Hi Konrad!
Yesterday I managed to boot liveslack-1.15.
I had the same response from mokutil.
Please read my comment above.
Short: BIOS UEFI enabled, secureboot disabled is your current state.
You can import liveslak.der, reboot to BIOS setup and enable secureboot there.
After that you enroll MOK following Aliens procedure above (blue screen shots) and proceed boot liveslack.
So you booted it in secureboot environment. Verify that with mokutil.
Thanks Zdenko !
I’ll ponder your post
— kjh
Slackware Live Edition supports SecureBoot starting with liveslak-1.5.0. Which means, your ISO labeled with liveslak 1.4.0.2 does not support it. Download the newer ISO to get that support.
UEFI Secure Boot Setup Mode allows you to erase the default keys (Microsoft’s) from the NVRAM – you would only do that if you want to replace them with your own. If that’s not your intention then you should switch from Setup Mode to USer Mode after which you should be able to enable Secure Boot. There should also be a way to restore the default Platform Keys if you had removed them earlier but want them back. I think that process is different with each UEFI firmware though – use an internet search to find the correct procedure for your motherboard.
Thanks Eric
I am refreshing my Slackware Live 1.4,x with the new 1.5,0 along with new versions of bonus/{0050-multilib,0060-nvidia}*
I’ll research my laptop for more info ion the state of Secure Boot ( it arrived from Sager that-a-way ).
Thanks again.
— kjh
Congratulations for your work Eric!
Fortunately, I don’t need it at the moment, since I don’t have MSW on my PC \o/ I hope I never need it. But.. if unexpected things happen, I know where I can look for the solution 🙂
All the best
my question is, will there be a day we are forced to keep secure boot enable, or will we be able to always disable secure boot on our own personal computers. I will at time to time compile my own kernal and don’t want to be bothered to do my own signing and loading.
You can always disable secure boot on your own hardware, or even keep it enabled but remove the Microsoft keys and load up your own self-generated keys instead.