Start Slackware installer without disabling UEFI Secure Boot first?
 

I might need to install Slackware on new hardware soon and I wonder if it's possible to start installer and install Slackware without disabling UEFI Secure Boot first. I have ASUS Z97-A and I have to disable Secure Boot before running Slackware installer or I get error message as shown here https://i.imgur.com/h4wOX5d.jpg (Secure Boot is enabled by default so I have to disable it explicitly). On the other hand I tried to run Ubuntu 20.04.1 LTS ISO with Secure Boot enabled and to my surprise it just worked. I don't know how it works but there are some details here https://wiki.ubuntu.com/UEFI/SecureBoot. Would it be possible to make Slackware work with Secure Boot enabled?

I doubt that Slackware Installer will ever start over UEFI Secure Boot, because from what I understand, the Slackware kernels and bootloaders aren't signed with Microsoft Secure Boot certificates.

However, the RHEL, SuSE or Ubuntu kernels and bootloaders are signed, then they will work in this environment.

So, in the Slackware case, I believe you must disable this feature - or IF you can't, you should throw the towel.

Yes, that's the reason but if they can do that couldn't Slackware do that as well?

So far I have always been able to disable Secure Boot but if I could run Slackware with Secure Boot enabled it would be slightly easier to install it because sometimes finding an option to disable Secure Boot in UEFI interface can take more than a while. I heard that motherboards manufacturers have to provide option to disable Secure Boot but what if this requirement changes or company policy prevents me from disabling it?

Yes, probably Slackware can sign its kernels and bootloaders too...

The catch is: IF someone convinces Mr. Volkerding to buy a Microsoft certificate for Slackware - BTW, from what I heard that this certificate costs like a really good sports car, i.e. Ferrari 488 Pista, then do the math about probability of seeing (or not) middle fingers if you ask for this.

However, you are aware that even the Slackware signs its things and ran fine over Secure Boot, you still will never be able to run your custom and unsigned kernels in the same way?

To run your own built kernel, you will need anyway to disable Secure Boot.

Or go to hell Microsoft Secure Boot with all their certificates!

Yes, you can install, and run, slackware64-current on a computer with secure boot enabled (I do it). You will need an existing machine running linux to prepare your boot sticks.

The easiest way, which is not in my view the best way, is to use the Linux Foundation's PreLoader.efi and HashTool.efi, and enrolling elilo.efi in your MOK using HashTool, which will be brought up the first time you boot. You can do this this way:

1. First you need a (non-secure boot) slackware boot stick with an actual real EFI partition, formatted for a VFAT file system with partition type "EFI System partition." (code EF00). One way of doing that is to delete every existing file and partition on the stick, and make an EFI partition on it. You can have, say, a second ext4 partition with the latest slackware current distribution on it, if your stick is big enough (a 10GB stick should do), or you can even have the whole stick as an EFI partition and put the slackware distribution on it.

2. Mount usbboot.img with 'mount -o loop [/path/to]/slackware64-current/usb-and-pxe-installers/usbboot.img /mnt/loop'

3. Copy the whole of its contents, including directory structure, to the EFI partition on the stick you have just made.

4. Go to the EFI/BOOT directory you will now have on the stick, move bootx64.efi to loader.efi (it is actually a copy of elilo.efi) and copy PreLoader.efi to the stick as bootx64.efi in its place. Copy HashTool.efi to EFI/BOOT as HashTool.efi.

Now you should be able to boot that stick in secure boot mode. The first time you boot the stick, PreLoader.efi will invite you to hash a file, and you should hash your loader.efi (the renamed original bootx64.efi which is a copy of elilo.efi). This works because PreLoader.efi has been signed by Microsoft's key for third party uefi applications, the public certificate for which will be in the computer's efi db, and Preloader.efi will in turn verify via the hash obtained from HashTool.efi what it is handing off to, namely elilo. Once you have installed slackware on your hard disk, via PreLoader.efi you should be able to boot off the same loader.efi (renamed as elilo.efi) whose hash you have entered above, in order to boot up your computer off the hard disk. You might as well keep a copy of HashTool.efi in your computer's EFI partition also in case you need it to enter a new hash for a new elilo.efi, and put an EFI boot manager entry for PreLoader.efi using efibootmgr to enable booting directly to it from the EFI boot manager to then hand over to elilo.efi.

But this is definitely not the best way to do it, although it is the easiest. It is not the best because it drives a coach and horses through the purpose of secure boot - elilo will be able to boot any kernel, secure or not. Better is to use fedora's shim with grub, whereby you can sign individual kernel images which you want to be able to boot. To do that on a new secure-boot-only system you need start with two boot sticks, the first to enroll your signing key in MokManager, and the second to boot up and install slackware after you have entered the key. To do this:

1. Obtain shim from Fedora's website (I use shim-x64-15-8.x86_64.rpm), explode the rpm and obtain the efi binaries shimx64.efi and mmx64.efi. shimx64.efi has been pre-signed by Microsoft's and fedora's keys but will only hand over to a kernel image which has been signed with a key entered in MokManager. mmx64.efi is the MokManager efi and is used to enter your key for that purpose.

2. Prepare a stick (Stick 1) with nothing on it except an empty EFI partition with the /EFI/BOOT directory on it. Copy shimx64.efi to it as bootx64.efi, and mmx64.efi as grubx64.efi.

3. Prepare a second stick (Stick 2) like the usbboot.img stick mentioned above, but without PreLoader.efi or HashTool.efi, and with shimx64.efi copied to /EFI/BOOT as bootx64.efi, and with the EFI partition as the first partition.

3. Generate a MOK signing key with:
This will provide the MOK certificate in both PEM (MOK.crt) and DER (MOK.cer) forms. The private part is MOK.key. Copy MOK.crt and MOK.cer to /BOOT/EFI on Stick 1 (MokManager requires the DER form but you might as well include the PEM one as well).

4. Prepare a grub image as follows:

Sign the generated grub64.efi.unsigned grub image with your signing certificate using sbsign-tools (which you will have to install yourself). Copy the signed version as /EFI/BOOT/grubx64.efi on Stick 2.

5. Move huge.s on Stick 2 to huge.s.unsigned and sign it also with your signing certificate as huge.s.

6. Put a grub.cfg file in /EFI/BOOT on Stick 2 with something like this in it:

I say "something like" because my directory structure is slightly different and this one follows the structure of usbboot.img referred to above. [sdaX] should be the intended root slackware partition on your computer's hard disk after installation. Grub should be able find the root directory for the huge.s kernel image and initrd.img image by itself if the EFI partition is the first partition and those images are in that partition.

7. Then boot with Stick 1 and enter your public signing key MOK.cer in MokManager.

8. Then boot with Stick 2 and install slackware.

9. Once you have installed slackware, you can boot it up with Stick 2 using the "Boot Slackware" entry mentioned, but you will also want to make a directory "grub" in /boot/efi/EFI, copy to it your signed grub image referred to above as grubx64.efi, copy shimx64.efi to it, sign also your current /boot/vmlinuz kernel image on your computer, have a grub.cfg file in /boot/efi/EFI/grub/ with an appropriate stanza to boot up your signed /boot/vmlinuz, and provide a EFI boot manager entry for shimx64.efi using efibootmgr (and make it the default boot menu item) so you don't have to go to the EFI boot manager every time you boot.

Every time you install a new slackware kernel you will have to resign /boot/vmlinuz with your key. I think that is about it. If anything else comes to mind I will do an edit. All this assumes that your new computer comes with Microsoft's public key for third party uefi applications already installed. I think that at present all consumer computers do, but if it doesn't you are stuffed. Caveat emptor.

Edit: If all you want to do is to run a slackware computer in secure boot mode that has already had slackware installed on it while secure boot was off, that is obviously a lot easier. You could just go to /boot/efi/EFI/Slackware, move elilo.efi to loader.efi, install PreLoader.efi as elilo.efi and install HashTool.efi and reboot with secure boot enabled, and then enroll elilo.efi (as renamed as loader.efi). Or you could make a /boot/efi/EFI/grub partition, prepare it with the shim, grub and mmx images as mentioned above and an accompanying grub.cfg file, and sign /boot/vmlinuz. You could then add two new entries to your EFI boot menu using efibootmgr, one to boot shimx64.efi which then boots straight into mmx64.efi (by renaming mmx64.efi as grubx64.efi) so you can enter your signing key without the need for a boot stick, and another (the default boot) to boot into shimx64.efi which will then hand off to the real grubx64.efi, thence to the signed kernel image.

IMHO Secure Boot is yet another bullying tactic literally as criminal as Armed Robbery. MS routinely uses the power of 90+% market share, with claws firmly embedded in Military, Government, Education, and almost everything that matters in society to a degree that emphasizes "Power Corrupts". Frankly I consider Debian and RedHat cowardly for having caved in to what amounts to mildly terrorist ransom. I seriously doubt that Mr. Patrick Volkerding or ANY of the contributers is so weak and unprincipled.

MS reminds me of this guy --- Only ONE ---

Totally agree with you sir.
P.S. I have been working in education for 20 years and I know what I'm talking about!

I bought a laptop several months ago, which have no way to disable Secure Boot.

Permit me to doubt that the radical opinions about Secure Boot will help to grown up the Slackware user base...

Yes. It is possible to install and run Slackware with secure boot enabled because I recently installed 14.2 with secure boot enabled.

It wasn't untill a bit later that I began to wonder whether I had disabled secure boot when I replaced the motherboard so went looking that I found secure boot was enabled.

Secure boot is now disabled, but several things are disabled by the BIOS.

My machine requires a EFI partition, so your machine probably will too.

From memory, the EFI partition is 240M and set using cfdisk as part of the install and is listed in my fstab.

Warning. When partitioning the drive the system (I used cfdisk) kept wanting to list my root partition as a Microsoft partition and assign the EFI partition with the boot flag. Thus make sure the root partition is linux.

When the install finishes use gparted to check and possibly move the boot flag from the EFI partition to the root partition.

@chrisVV, thank you, it works - I knew it's worth asking!

I followed the first method you described but this was actually easier than I thought - I've just mounted the second partition of Slackware install disk and added and replaced all of the files as you described.

It would be cool if this was integrated in the stock installer, ideally without that Hash Tool menu in between.

Have you returned it as it is obviously defective? If not you are part of the problem.

That very idea that I must add something signed by Microsoft to boot my computer appalls me. As long as I can disable secure boot, I will continue do so.

I suppose the very fact that you consented to buy a PC in which your are forced to use MS code with no ability to opt out is good evidence that you would consider such a thing "grown up". That aside, just what is it that you think Secure Boot does to benefit you?

Well, honestly I didn't expect such answers. IMO you think too emotionally.

Imagine a beginner Linux user who tries various distros - Suse, Debian, Fedora and they all boot and work fine. Next thing he/she wants to taste is Slackware because real UNIX, the oldest living distro blah blah and so on. They want to run the installer and what - huge red error, INSECURE stuff. What do they next depends, some people might be dedicated but some will not touch Slackware any more in their life and the only thing they will remember about it is 'the thing that didn't even boot'.

Here https://www.howtogeek.com/116569/htg...eans-for-linux and in many other places it says that it costs 99 USD. How do you know it's so expensive?

The problem will be when the user can't disable the secure boot in the UEFI bios in the future.

I don't see this as emotional at all. I vastly prefer that at least one distro demonstrates it's commitment to more than the lowest common denominator. Slackware gives a great deal of power and choice but that isn't free. That requires you earn it by actions more meaningful and important than being led around by a Microsoft leash, no matter how comfortable the collar. Yes, there is emotion included in such views but they begin in cold, hard logic and strength of will.

First off, there is very good information in this thread for those who want to use secure boot. Thank you for this post ChrisVV!

Imagine a seasoned user of Linux or other alternative operating system finding out they can no longer run their chosen operating system without getting permission from Microsoft first.

Imagine you are a Windows 10 user and your computer doesn't start because secure boot is turned on.

As for someone wanting to try Slackware and it fails to boot because of secure boot, they can come here to find a solution. If they don't want to take the time to figure things out then Slackware is probably not for them. Secure boot isn't all as secure as Microsoft wants you to believe. Search the internet for BootHole (CVE-2020-10713) attack. Around March of this year, Windows 10 was having issues with secure boot failures.

As a personal computer user I see no advantage on using Microsoft's secure boot.

Secure boot is possible without purchasing anything from Microsoft. Maybe that wasn't always the case. But today, you can create some cryptographic key pairs, update your bios with the keys so it will recognize a signed kernel, and then create an efi_boot configured kernel and sign it with said keys. Your hardware will now secure-boot without purchasing anything from Microsoft. Therefore, that particular bias is no-longer justified.

However, to update the bios with your keys, secure-boot needs to be temporarily disabled.

Therefore, there is still a reason to be disgruntled about any device that had no means to disable it.

Check this out.

You should be able to use the Linux Foundation's PreLoader, or fedora's shim, to bring up any kernel you like, including for the purpose of installing your own secure boot keys. However, having brought up any kernel you like, why bother - why not just rely on the MOK that you used to bring it up? The answer is, if Microsoft's third party signing certificate is not installed in your computer's key database: however if that is the case, and you cannot disable secure boot, then you really are in trouble. But I don't think any consumer computers are in that position.

@chrisVV, as I said I was able to start Slackware -current installer after following the first method you described but I still got the Secure Boot Violation error when booting newly installed Slackware system. You said:

But isn't bootx64.efi on Slackware -current installation disk from https://bear.alienbase.nl/mirrors/sl...64-current-iso actually GRUB and not elilo? I thought that after installing Slackware I could just copy loader.efi to /boot/efi/EFI/Slackware/elilo.efi and this actually works but since this is GRUB and not elilo I just get GRUB shell and Slackware doesn't boot. Do you think I should re-use HashTool.efi and PreLoader.efi to sign elilo.efi that is used to boot installed Slackware system?

Again, what does Secure Boot actually bring to the table as a Benefit and at what Cost? That is by definition, The Bottom Line - Profit or Loss?.

bootx64.efi on the Slackware installation disk (if by that you mean a mounted version of the slackware distribution) is indeed a grub image. You can copy the whole distribution onto an EFI partition if it is big enough and it will be bootable. If you did that, well done for trying it, but it wasn't my suggestion.

My suggestion was that you should copy the files in the slackware usb boot image to the EFI partition on your stick, as that is generally easier as it is a lot smaller. To do that you need to follow steps 2 and 3 before step 4: "2. Mount usbboot.img with 'mount -o loop [/path/to]/slackware64-current/usb-and-pxe-installers/usbboot.img /mnt/loop' 3. Copy the whole of its contents, including directory structure, to the EFI partition on the stick you have just made." That image uses elilo for EFI boots.

You can use whichever approach you want if you know what you are doing. But explaining more clearly what you have done would be helpful.

On "I still got the Secure Boot Violation error when booting newly installed Slackware system", if you are booting the entire distribution you should do the equivalent to what I suggested in relation to slackware's USB boot image: move bootx64.efi to loader.efi, copy PreLoader.efi to your EFI boot medium as bootx64.efi in its place, copy HashTool.efi onto the boot medium and on first boot-up enroll loader.efi. If what you have done is to burn a DVD (you don't say) you would need to assemble all this before burning.

Edit: On your "Do you think I should re-use HashTool.efi and PreLoader.efi to sign elilo.efi that is used to boot installed Slackware system?", I have already dealt with that. As I said, you can move elilo.efi to loader.efi and install PreLoader.efi as elilo.efi. But my overall suggestion was that you should use shim instead.

ok, what I did is I downloaded slackware64-current-install-dvd.iso from https://bear.alienbase.nl/mirrors/sl...64-current-iso, copied to my USB stick:

Then I mounted the second partition of the USB stick, renamed bootx64.efi to loader.efi and tried to copy PreLoader.efi but the partition turned out to be too small:

I backed up bootx64.efi (now loader.efi) and enlarged the partition using fdisk:

I re-created FAT filesystem, restored EFI directory structure and /tmp/bootx64.efi:

I renamed bootx64.efi to loader.efi and copied PreLoader.efi and HashTool.efi:

I enabled Secure Boot in ASUS UEFI settings, booted using the USB stick and was welcomed by 'Hash Tool main menu' and I enrolled hash to loader.efi as shown here https://imgur.com/a/PfPXM33. I have then started the installer but I haven't installed the system, I have disabled Secure Boot and ran my current installation in order to back up important stuff. Next, I have installed Slackware from the USB stick and ran the newly installed system. I have re-enabled Secure Boot in hope that Slackware would just start but I got Secure Boot Violation when booting it as shown at https://i.imgur.com/h4wOX5d.jpg.

So, that's what I did.

I don't know, ask Microsoft and Intel.

In /boot/efi/EFI/Slackware you will have to move elilo.efi to loader.efi, install PreLoader.efi as elilo.efi and install HashTool.efi, and enroll loader.efi again. It looks as if the file system, as well as the file, forms part of the hash. But I think shim is a better choice.

This is a goldmine of good info. I suggest making this topic sticky or even including a howto based on it on the base Slackware documentation.

ok, so at the end of the day I should use HashTool twice - first to sign GRUB that starts the installer and then to sign elilo.efi that boots installed Slackware system.

You mean the second method you described here https://www.linuxquestions.org/quest...7/#post6165346? From what I understand it would require more work in the future with every new kernel. I just want to run Slackware without thinking about Secure Boot on hardware that does not belong to me.

Yes, there should also be an article on that at https://docs.slackware.com. I might write one. It would also be good if one of the methods described in https://www.linuxquestions.org/quest...7/#post6165346 was added to the stock installer but it's up to Pat.

I can't know if you were serious but it should be obvious they can't answer for me. What is far less obvious is what good Secure Boot can possibly offer Slackware or Linux as a whole. Since Microsoft and Intel don't emphasize Linux (and who really can blame them?) it's unlikely any meaningful answer will be forthcoming. In the meantime I rely on "If it ain't broke, don't 'fix' it".

On the flip side we have entered an era where firmware is just software and can be attacked by malware underneath any OpSys. How much damage that can cause is largely OpSys dependent and is still to play out. How effective Secure Boot is in defense against such attacks, especially for Linux, is an ongoing battle.

That's why I ask the cost/benefit question.

They can't answer for you so you decided to ask some random dudes on the internet. Fine.

I don't know what do you expect from them but Intel contributes a lot of code to Linux, see https://git.kernel.org/pub/scm/linux...ee/MAINTAINERS or LKML.

I want to make it work at all, not fix it. According to https://www.howtogeek.com/116569/htg...ans-for-linux:

And someone in this thread has already come across a computer on which Secure Boot cannot be disabled https://www.linuxquestions.org/quest...7/#post6165463

https://support.microsoft.com/en-us/contactus
https://www.intel.com/content/www/us...t-support.html
https://www.asus.com/us/support/callus

I thought I had a similar issue to ZhaoLin1457 with not being able to disable secure boot on a laptop. I emailed the manufacturer, and they said that you needed to first create a bios password. Having done this, and restarting, the bios option to disable secureboot appeared!. After disabling it, i could clear the bios password I had temporarily added, and hey-presto! secure-boot disabled, and I could set up dual boot with slackware without having to go through all the hoops described.

What laptop model do you have?

I own and provision x86_64 and arm64 devices, both which have secure-boot (mainline u-boot can store secure-boot-keys); linux kernel can uefi boot with efi_boot_stub configured... so one way to configure booting that works everywhere is handy, though not profitable, per se.

I fixed an apple guy's imac's time machine's mess: I put my portable ssd with slackware64 on it, (which has /boot/efi/EFI/BOOT/BOOTX64.efi), and held the option key during startup, and behold, the portable ssd was available, and I was able to run his imac on my ssd, then mount his imac's internal drive, and use rsync to merge all the copies of copies inside itself that his time machine setup had created... he was really grateful and gave me some bucks (profit). If he had had a secure-boot computer, it would have been more challenging, as this thread discloses, and I would have missed out.

Having a portable slackware installation that can boot a customer's secure-boot device leads to profit! Even though, from a security point of view, secure-boot might not have helped slackware or linux--in fact it created a hindrance by needing more work to make it work--nevertheless, having a secure-boot equipped slackware allows access to those devices that would otherwise be hindered, and that access can be profitable!

The question originally posed was in the title: "Start Slackware installer without disabling UEFI Secure Boot first?", positing also subsequently the possibility of having a computer on which it cannot be disabled (which is indeed possible with Windows 10 onwards).

If you cannot answer that question why not be silent rather than trying to take the thread over for your own purposes. Stating your highly predictable views on a different question, namely whether secure boot is a Microsoft conspiracy ("Armed Robbery" as you put it) or has an adequate cost/benefit ratio, might be acceptable if done once, but to keep going on and on I don't think is.

It is a shame when someone tries to turn a technical discussion into yet another twitter-style righteousness war.

Thanks slac-in-the-box. I concur about portable Slackware installs as a great investment. However I still get the strong impression that Secure Boot is like offering a new car with the salient feature that it requires two sets of keys to start it.

@ZhaoLin

I also would like to know so that I can avoid
this brand of laptop and circumvent their sordid plot of entrapment.
谢谢您的配合.