My thoughts on Slackware, life and everything

Tag: boot

Secure Boot support landed in liveslak 1.5.0

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

Out of the box PXE install server in Slackware 13.37

I had a lot of fun creating my Easter Egg for Slackware 13.37. It did not matter that Pat announced it on the slackware.com front page – it’s OK that it got some exposure. The added functionality is useful enough.

So, why an easteregg at all… and what about that PXE server?

In the last weeks before the eventual release it became pretty clear that the go-live date would be somewhere around Easter. All showstoppers had been dealt with. There was a bit of leeway and I skimmed through my TODO file (where I write down the ideas I get for Slackware improvements, as well as reminder notes for fixes that I think are important but not urgent). One of the ideas I wanted to implement was a PXE server that would run out of the box when booting the Slackware DVD.

I decided to do a quick hack session and come up with a proof of concept to see if it worked. Initially my plan was to incorporate the result into a custom initrd to be posted on my own web site, but after two (long!) nights of trying I had something that could be tested by others in the core team.

My good pal mRgOBLIN is a willing subject for this kind of non-public testing. He hammers at everything network related that I add to the installer, and he tends to find all the bugs and corner cases.

Two more days, and I had something that was working well, complete with documentation, and Pat Volkerding added it without hesitation and without mentioning it in the ChangeLog.txt. It has been inside the Slackware installer since April 15… and no one noticed. This was intended as an easteregg (well, at least that’s what I kept calling it) but it adds real valuable functionality to the installer. It’s more than just a prank.

Writing the scripts actually uncovered a couple of bugs in the network configuration of the installer which I fixed. Therefore I decided to write an article about how this “pxeserver”can be used by you.

You probably know that I have an article in my wiki about setting up a PXE boot server for network installation (it’s at http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:pxe) which is what Slackware’s “usb-and-pxe-installers/README_PXE.TXT” file is based on. But even with all the details in those instructions, it’s still one bridge too far for many people – and not everybody has the luxury of having a Slackware server running in his network.

Setup a PXE server

So, one of the ideas written in my TODO file was “add a PXE server to the Slackware installer“. My intention was to provide an easy method for network installations of Slackware, provided you have one spare computer with a network card (no wireless!!!). This is how it goes, using the Slackware 13.37 installation media:

You insert the Slackware 13.37 DVD (or CD1) into the spare computer, and boot from the optical medium:

Instead of typing “setup” as usual, you type “pxesetup” this time:

The “pxesetup” script will load a main dialog which is modeled after the Slackware setup:

There are four relevant main selections (apart from EXIT which will drop you back to the prompt): HELP, NETWORK, SOURCE and ACTIVATE. I will go through these choices using the screenshots below, and you will see that there is surprisingly little for you to configure… it is very user-friendly.

HELP:

The HELP section should be self-explaining – it is the manual for the PXE server:

NETWORK:

The NETWORK section is where you determine how the computer’s network card gets configured:

If you boot this PXE server in a network with a DHCP server for automatic network address assignment (as is the case with your typical domestic setup where the Cable/DSL router provides the DHCP server) then pxesetup will prompt you to use that. It saves you from typing IP addresses and netmasks. You can of course still decide to enter a specific static IP address even if there is a DHCP server available, by clicking “No”:

If no DHCP server was found in your local network (Slackware’s installer checks this when it boots and before you even see the command prompt), then have no choice but to enter a static IP address, netmask and possibly (but not necessarily) a default gateway:

After the network interface has been configured, you will see a number of dialogs that let you determine whether the installer should start a DHCP server or not. If your network already runs a DHCP server, then it should not be disrupted by a “rogue” DHCP server. Instead, pxesetup will only provide the netboot functionality by acting as a proxy DHCP server,:

A working DHCP server is required for PXE boot. So, if your network does not provide one, pxesetup will start its own built-in DHCP server and it will show you two additional dialogs in order to collect the required information:

The setup program tries to make an educated guess about the range of IP addresses to be used if it is going to start a DHCP server. A dialog will present the proposed configuration. There are two configurable items in that dialog: the lower and upper values for the IP address range that will be used by the built-in DHCP server.

The IP addresses in this range will be available for the PXE clients that request a network boot configuration from the PXE server. Please check this address range, and if you think you have a computer in your network that uses an IP address in this range, you can change the values for the upper and/or lower values and resolve the conflict. This range of IP addresses must not be used by any computer on your LAN !

If you are satisfied with the values, select “OK” to continue to the next section.

SOURCE:

The SOURCE section uses the exact same dialog screens as you know from the Slackware installer. The only correct selection is “Use a Slackware DVD” (There is one exception which I will explain in more detail all the way down, and that is when you used the “usbimg2disk.sh” script to create a complete Slackware installer on a bootable USB stick):

The pxesetup program will find the Slackware DVD or CD and that’s it! More information is not required and the PXE server will be started automatically. Another service is started as well at that moment: a HTTP server which will serve up Slackware packages to the clients that use our PXE server.

On-screen you will see the log file of the dnsmasq program which provides most of the netboot functionality. The first screenshot is the case where your network provides a DHCP server, while the second screenshot shows the situation where the Slackware PXE server has started its own internal DHCP server:

You can press the “EXIT” at any time, which will kill the PXE services (DHCP, TFTP and HTTP). You can then restart these services from the main menu again, by selecting the ACTIVATE entry.

PXE server works, what about PXE clients?

There is no fun with a PXE server if you do not have PXE clients that use it to boot from so that you can install Slackware on them! Make sure that the computer that you want to install Slackware on is connected to the network with a cable, and power it up. In the BIOS (or using whatever method is available for that machine) select “LAN boot” and watch what happens when the computer boots. You will see a prompt that says:

Press [F8] for a boot menu…

Actually pressing the [F8] key gives you two choices: continue with netbooting, or fallback to boot-up from the local hard disk. Or if you don’t do anything at all (takes 2 seconds only) your network card will start looking for a PXE server and the communication starts. This can be witnessed on the PXE server’s screen:

What happens next should all look pretty familiar: the Slackware welcome screen will appear and you can either press [ENTER] for the default kernel or make your own choice of parameters. The noteworthy part is where you get to select the package SOURCE. There is only one working option, and that is “Install from FTP/HTTP server“. After selecting this option, your computer’s network card will be configured using DHCP, and then you will notice that the questions for “URL of the ftp or http server where the Slackware sources are stored” and “What is the Slackware source directory?” have default values already filled-in! You should accept these values, since they are supplied by the PXE server!

The remaining steps should be familiar if you have ever tried installing from a HTTP server before.

  • Using a USB based installer instead of the CD/DVD !

I hinted at using a USB installer earlier on. So what else did I cook up? The most recent change I made to the “usbimg2disk.sh” script which you find in the “usb-and-pxe-installers” directory on the DVD or any Slackware mirror, added some functionality for running the PXE server off the USB stick. You need to create a full USB installer for this to work (“full” meaning that the USB stick is made bootable and all Slackware packages are copied to the stick).

  • If you boot this USB installer, the vfat partition on the USB stick (which contains the Slackware packages) will be automatically mounted on directory “/usbinstall”.
  • If you run “pxesetup” (or even if you run the normal “setup” by the way) and come to the point of selecting the packages location in the SOURCE menu, you should pick “3: Use a pre-mounted directory“. Actually, that item will be the default choice! When you select that option, you will notice that there is a value for that directory name already filled in. All you have to do is to accept that directory name.
  • Any questions? Leave them in the comments section below and I will answer them.

    Have fun! Eric

    By the way, have I ever told you how I hate the layout engine of wordpress? I am unable to make this post look the way I want it. Or is it the template? Apologies for the awkward placement of the images.

    Welcome Windows user!

    … I am going to show you how to create a Slackware USB installer when all you have is a Windows computer.

    As a Linux user, this would not cause you any problems since there is a shell script that does the work for you – all you need is the Slackware DVD and a re-usable USB stick of sufficient size.

    If you run Windows, it is still possible to create a bootable USB stick that can start Slackware’s installer. If the stick is big enough (2 GB in size) you can even add Slackware’s packages to it and avoid the use of a Slackware DVD as the package source entirely.

    The requirements:

    What tools will you need for the job at hand?

    • A version of dd for Windows. This is needed to copy a USB image file to the USB stick. You can obtain it here at chrysocome.net., the same site that also hosts RAWRITE.EXE which ships with Slackware in the isolinux/sbootmgr directory.
    • The syslinux tool from syslinux.zytor.com. This will be used to make your stick bootable. Download it directly from kernel.org – the .zip file contains a Windows executable.
    • A program like Winimage (a shareware program, free 30-day trial), or IZarc (might be a good free alternative to Winimage) that is able to open the usbboot.img disk image file and extract its content to your hard drive.
    • Of course you need a Slackware DVD. Either buy it at the Slackware Store (which helps keeing the distro alive) or download a DVD ISO image from any Slackware mirror. It is also possible to use a local copy of a Slackware package tree (either downloaded from a Slackware mirror or copied off a DVD). In the examples below I am using “slackware-13.0” which is the 32-bit Slackware version 13.0. The instructions are not limited to this particular version of Slackware – you can do this for every recent version of Slackware, including the 64-bit release.
    • And finally, a USB stick with a (single) FAT32 partition. If it has 40 MB of  free space, you can use this stick as a bootable Slackware installer but still need the DVD or a set of CDROMs for the actual packages. If the stick has 2 GB of available free space, you will be able to copy all Slackware packages to the stick as well. The resulting bootable USB stick will be all you need in order to install Slackware. Ideal for netbooks that do not have a DVD drive!

    Preparations:

    First things first:

    1. Insert the Slackware DVD or make sure you have a copy of a Slackware tree somewhere on your local drive (more specifically: everything on the Slackware DVD with the exception of the source and slackbook directories will be required). In the examples below I will assume that the top of the Slackware tree is “D:\slackware-13.0\“. For other releases of Slackware or for the 64-bit version of Slackware the pathnames will be a bit different of course, but the same procedure applies.
    2. Insert the USB stick, make sure it gets assigned a drive letter. In the examples below I assume that the drive letter for the USB stick is “U:
    3. Now, you have to decide what to do with your stick. This depends on how much data it can contain (less than 2GB, or more than 2GB). See below, there is a set of instructions for both cases.

    If you have (much) less than 2 GB available on the stick, we can transform the stick into a bootable Slackware setup disk.

    NOTE: the following procedure will erase all existing data on the USB stick, so be careful and check what’s on it before you proceed.

    1. Install the Windows version of dd (see above) onto your Windows computer.
    2. Open a DOS box (i.e. get a command prompt) by running
      cmd.exe
    3. Run the following command at the prompt:
      dd if=d:\usb-and-pxe-installers\usbboot.img of=\\.\u:
    4. That’s it! You have created a bootable Slackware setup USB stick

    If you have 2 GB or more available on the stick, we will be creating a full “USB equivalent” to a Slackware DVD:

    NOTE: The following procedure is non-destructive; meaning that no files on the stick will have to be deleted.

    1. Install Winimage and the Windows version of syslinux (see above) onto your Windows computer.
    2. Create a directory “U:\boot\syslinux\” on the USB stick
    3. Use Winimage to extract the content of the image file “D:\usb-and-pxe-installers\usbboot.img” to the newly created directory “U:\boot\syslinux\” on the stick
    4. Remove the file “U:\boot\syslinux\ldlinux.sys
    5. Open a DOS box (i.e. get a command prompt) by running
      cmd.exe
      On Vista at least, you have to run cmd.exe as Administrator to avoid the “Accessing physical drive: access denied” message when running the syslinux command in the next step.
    6. Run the following command at the prompt to make the stick bootable (you will notice the directory /boot/syslinux in that command which is the directory we just populated):
      syslinux.exe -m -a -d /boot/syslinux u:
    7. Using Windows Explorer, give the U: drive the label “USBSLACKINS
    8. Copy the whole Slackware tree “D:\slackware-13.0” to the root of the USB stick, “U:\“. Exclude the slackbook, source and usb-and-pxe-installers directories while copying if you have just about 2 GB free. If you have a 4 GB stick you will find that everything will fit nicely. Using a Windows Explorer for this is probably easiest. As the end result you should have a “U:\slackware-13.0” directory on the stick with (among others) a file “PACKAGES.TXT” and a directory “slackware” below that.

    Booting the USB stick and installing Slackware:

    When booting this USB installer (the version containing the Slackware packages), you have to mount the USB partition before starting “setup” because you can access your packages only after mounting it. You cannot use the directory “/mnt” to mount this partition because the Slackware installer uses “/mnt” already. After the booting has finished and it delivers you to a command-prompt, you create a new directory in the installer, for instance “/usbinstall“:

    mkdir /usbinstall

    After you have created this mount point, you have to find out the name of your partition (you can run “fdisk -l” or “blkid” to find out) and then use the following mount command to preserve upper case filenames:

    mount -t vfat -o ro,shortname=mixed $(/sbin/blkid -t LABEL=USBSLACKINS | cut -f1 -d:) /usbinstall

    The “shortname” option used in that mount command is required, and Slackware installation will fail if you forget it.

    If you labeled the stick’s partition “USBSLACKINS” in step 7 above, then you can use the following command instead of the previous mount command. It will find the correct partition automatically (note that what follows is a single command line !):

    mount -t vfat -o ro,shortname=mixed $(/sbin/blkid -t LABEL=USBSLACKINS | cut -f1 -d:) /usbinstall

    Then afterwards, when it is time to specify the package SOURCE directory, you type:

    /usbinstall/slackware-13.0/slackware

    The rest of the installation will proceed as usual. Give me feedback in the comment section below if you encounter any problems.

    Good luck! I hope this small tutorial will be able to snatch you away from the Dark Side 😉

    Eric

    © 2024 Alien Pastures

    Theme by Anders NorenUp ↑