LinuxQuestions.org - Start Slackware installer without disabling UEFI Secure Boot first?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Start Slackware installer without disabling UEFI Secure Boot first? (https://www.linuxquestions.org/questions/slackware-14/start-slackware-installer-without-disabling-uefi-secure-boot-first-4175682037/)

Quote:

Originally Posted by LuckyCyborg (Post 6165333)

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.

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.

Quote:

Originally Posted by average_user (Post 6165857)

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'.

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.

Quote:

Originally Posted by average_user (Post 6165857)

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.

Quote:

Originally Posted by slac-in-the-box (Post 6166104)

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.

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.

Quote:

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.

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?.

Quote:

Originally Posted by average_user (Post 6167215)

@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 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?

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.

Quote:

Originally Posted by chrisVV (Post 6167243)

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:

Code:

cp slackware64-current-install-dvd.iso /dev/sdc

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:

Code:

$ udisks --mount /dev/sdc2

Mounted /org/freedesktop/UDisks/devices/sdc2 at /media/Slackware-current DVD

$ cd /media/Slackware-current\ DVD/

$ df -h .

Filesystem      Size  Used Avail Use% Mounted on

/dev/sdc2      1.4M  1.4M  39K  98% /media/Slackware-current DVD

[ja:/media/Slackware-current DVD/EFI/BOOT] $ mv bootx64.efi loader.efi

[ja:/media/Slackware-current DVD/EFI/BOOT] $ cp ~/secure-boot/PreLoader.efi bootx64.efi

cp: error writing 'bootx64.efi': No space left on device

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

Code:

$ cp loader.efi /tmp/bootx64.efi

$ cd

$ udisks --unmount /dev/sdc2

$ fdisk /dev/sdc



Welcome to fdisk (util-linux 2.27.1).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.





Command (m for help): p

Disk /dev/sdc: 59.7 GiB, 64055410688 bytes, 125108224 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x0cc08a3d



Device    Boot Start    End Sectors  Size Id Type

/dev/sdc1  *        0 6823935 6823936  3.3G  0 Empty

/dev/sdc2        2764    5643    2880  1.4M ef EFI (FAT-12/16/32)



Command (m for help): d

Partition number (1,2, default 2):



Partition 2 has been deleted.



Command (m for help): n

Partition type

  p  primary (1 primary, 0 extended, 3 free)

  e  extended (container for logical partitions)

Select (default p): p

Partition number (2-4, default 2): 2

First sector (6823936-125108223, default 6823936):

Last sector, +sectors or +size{K,M,G,T,P} (6823936-125108223, default 125108223): +2M



Created a new partition 2 of type 'Linux' and of size 2 MiB.



Command (m for help): w

The partition table has been altered.

Calling ioctl() to re-read partition table.

Re-reading the partition table failed.: Permission denied



The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

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

Code:

$ mkfs.fat /dev/sdc2

$ udisks --mount /dev/sdc2

$ cd /media/Slackware-current\ DVD/

$ mkdir -p EFI/BOOT

$ cd EFI/BOOT/

$ cp /tmp/bootx64.efi .

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

Code:

$ mv bootx64.efi loader.efi

$ cp ~/secure-boot/PreLoader.efi bootx64.efi

$ cp ~/secure-boot/HashTool.efi .

$ md5sum  *

45639d23aa5f2a394b03a65fc732acf2  HashTool.efi

4f7a4f566781869d252a09dc84923a82  bootx64.efi

a837b160476f55e66041292836f3fbe9  loader.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.

Quote:

Originally Posted by enorbet (Post 6167234)

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?.

I don't know, ask Microsoft and Intel.

Quote:

Originally Posted by average_user (Post 6167259)

... So, that's what I did.

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.

Quote:

Originally Posted by chrisVV (Post 6167268)

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.

Quote:

Originally Posted by chrisVV (Post 6167268)

But I think shim is a better choice.

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.

Quote:

Originally Posted by sombragris (Post 6167277)

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.

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.