LinuxQuestions.org - [SOLVED] ?//have you guys heard from m$ recently?

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

- - ?//have you guys heard from m$ recently? (https://www.linuxquestions.org/questions/slackware-14/have-you-guys-heard-from-m%24-recently-4175725091/)

Quote:

Originally Posted by business_kid (Post 6431232)

the day will come when it clears out and blacklists all keys in nvram. Then Alien's liveslak or slackware won't boot because it's key has been blacklisted.

As far as I understand it, the Microsoft signing keys that were used to sign vulnerable bootloader binaries will be blacklisted. As a consequence, those vulnerable bootloaders will no longer be allowed to boot your computer because its signing public key is gone.
But Alien Bon signs his bootloader with his own (non-microsoft) key, which is why you have to import his certificate (the public key) into the MOK. His certificate will therefore remain usable and liveslak ISOs remain bootable under Secure Boot.

The next time I decide to upgrade and find no decent motherboards have CSM/Legacy included or force Secure Boot, I intend to resort to UEFItool (modern version of modbin as I understand it) and have my way with it.

Quote:

Originally Posted by enorbet (Post 6431246)

Usually, the Secure Boot only motherboards has no CSM/Legacy module in UEFI because I guess it makes no sense in this design.

So, your "or" is rather superfluous. ;)

Quote:

Originally Posted by business_kid (Post 6431232)

Then Alien's liveslak or slackware won't boot because it's key has been blacklisted. But I can boot windows 11 (hurray:rolleyes:). I then do what exactly?

Surely, he'd acquire a new shim when and if that happens. This whole mess is just one more reason why Windows belongs on VMs and not bare metal, so far as I'm concerned.

Quote:

Originally Posted by pghvlaans (Post 6431262)

Surely, he'd acquire a new shim when and if that happens. This whole mess is just one more reason why Windows belongs on VMs and not bare metal, so far as I'm concerned.

In fact, all he will do will be the downloading of a new shim package from Fedora repos.

Anyway, considering the whole mess of Slackware's boot managers and kernels management, the replacing of 2 EFI binaries in the ESP would be rather a fart in the wind...

People, let's be honest. IF by the grace of Santa Claus, overnight all Windows users would start using Slackware, each day in this forum would be over 10000 new threads about broken boots. :p

And yes, I know about what I talk, because I have used various Microsoft software since I have built from scratch my first IBM PC/XT compatible. It was 40 years ago, or something. In fact, even before, because the first seen Microsoft software was games for a Z80 computer, also built from scratch. Lots of fun and soldering in that old times.

Hey, the people still do this from scratch. This video bellow made me remember of that old days. :D

https://www.youtube.com/watch?v=MW5lApN0gWc

I dont think I'm old enough to say this yet... but back in my day bootloaders weren't this complicated.

https://www.youtube.com/watch?v=qpMvS1Q1sos

Quote:

Originally Posted by Windu (Post 6431243)

As far as I understand it, the Microsoft signing keys that were used to sign vulnerable bootloader binaries will be blacklisted. As a consequence, those vulnerable bootloaders will no longer be allowed to boot your computer because its signing public key is gone.
But Alien Bon signs his bootloader with his own (non-microsoft) key, which is why you have to import his certificate (the public key) into the MOK. His certificate will therefore remain usable and liveslak ISOs remain bootable under Secure Boot.

Aahh. If that's wrong, please correct it. If that's right, It nicely dispels all the FUD, and I can relax. In fact the only ones who get caught then are the the distros who sucked up to M$ in the first place and had their shim registered.

As for modern boxen not working on Legacy, they probably do work on legacy. You need

the box set on legacy
No gpt disks but at least one MBR one.
An old fashioned boot loader.

Most folks forget the MBR formatted disks, and the old fashioned boot loader.

Quote:

Originally Posted by Pithium (Post 6431275)

I dont think I'm old enough to say this yet... but back in my day bootloaders weren't this complicated.

https://www.youtube.com/watch?v=qpMvS1Q1sos

I forgive you your youtube link:rolleyes:

No bootloaders weren't that complicated but every other week you got the Form boot virus, or Ping Pong, or half a dozen others. I was lucky enough to avoid having my BIOS chip overwritten on pc & laptop because I ran a checker for the CIH boot virus on April 23rd. The thing would overwrite the BIOS on April 26th! If I had suffered those consequences it would have been very difficult for my business.

Maybe I've misunderstood you, business_kid, but I have two different disks, one NVME and the other an SATA "spinner", both formatted with GPT partitioning and between them they have 6 Linux operating systems that boot from LILO, not elilo, LILO.

Quote:

Originally Posted by enorbet (Post 6431454)

You hardly have uefi in your BIOS, then?

EDIT: 40 Posts in this thread, with 53 "found this post useful" recommendations. Is that a record?

Quote:

Originally Posted by business_kid (Post 6431347)

As for modern boxen not working on Legacy, they probably do work on legacy. You need

the box set on legacy
No gpt disks but at least one MBR one.
An old fashioned boot loader.

It should work with gpt too, because gpt disks have a dummy mbr where you can load a small bootloader like LILO. It's a bit trickier with GRUB2 because only a stub goes in the mbr and the rest has to go somewhere else. On an mbr disk, it goes in the gap that's traditionally left between the mbr and the first partition, but on a gpt disk you need a separate first partition labelled as bios-boot and without a filesystem on it. Messy but doable.

Quote:

Originally Posted by hazel (Post 6431503)

Doable, as you wrote, and not so messy. In the code snippet below extracted from the current Slint intaller EFI is set only it the directory /sys/firmware/efi exists at time of installation:

Code:

    gettext "Installing the GRUB bootloader..."

    # Install with --target=i386-pc except in case of a GPT if no BIOS boot partition is available

    # in the same drive as the root one, which is allowed in manual partitioning mode and EFI booting.

    echo

    INSTALLINLEGACYMODE="yes"

    if [ "$(lsblk -lno pttype "$DRIVEPATH"|head -n 1)" = "gpt" ] && \

    ! lsblk -lno parttypename|grep -q 'BIOS boot'; then

        unset INSTALLINLEGACYMODE

    fi

    if [ "$INSTALLINLEGACYMODE" ]; then

        chroot $SLINT grub-install --target=i386-pc "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors

    fi

    # Install with --target=x86_64-efi except if there is is no ESP in the same drive as the root one.

    if [ "$AUTO" ] || [ -f $INSTALL/esppath ]; then

        if [ "$EFI" ]; then

            chroot $SLINT grub-install --target=x86_64-efi --bootloader-id=slint-$SLINTVERSION "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors

        else

            chroot $SLINT grub-install --target=x86_64-efi --no-nvram --bootloader-id=slint-$SLINTVERSION "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors

        fi

        cp  $SLINT/boot/efi/EFI/slint-$SLINTVERSION/grubx64.efi $SLINT/boot/efi/EFI/BOOT/BOOTx64.EFI

        echo "EFI\slint-$SLINTVERSION\grubx64" > /SLINT/boot/efi/startup.nsh

    fi

This way the installed system will boot in both EFI and Legacy modes regardless of the partition table type, except if the user chose to manually partition the drive but:

in case of a GPT did not set up a BIOS boot partition it will not boot in Legacy mode
did not set up en EFI system partition it will not boot in EFI mode

Sound a bit too much like work to me. The one laptop I messed with much here (A Samsung) was very strict about enforcing UEFI on a gpt disk. I believe Dell had a handier BIOS. What have you got?

Quote:

Originally Posted by business_kid (Post 6431536)

Sound a bit too much like work to me. The one laptop I messed with much here (A Samsung) was very strict about enforcing UEFI on a gpt disk. I believe Dell had a handier BIOS. What have you got?

In my computer's firmware setting menu the user can set the machine to boot either in EFI mode only or in EFI as well as in Legacy modes, regardless of the partition table type. Thus if I display the firmware's boot menu at startup I can choose to boot off the same drive in either legacy or EFI mode just selecting the relevant boot entry. This comes very handy for testing various configurations.

Quote:

Originally Posted by Didier Spaier (Post 6431538)

In my computer's firmware setting menu the user can set the machine to boot either in EFI mode only or in EFI as well as in Legacy modes...

Can recommend when buying new motherboard/pc to make sure all three options are available.

In a wild scenario where the certificate system collaps in a hack-feast :D it's nice to have a simple old system to run one's trusted platform...

But I like being a simpleton :rolleyes: so as long as it's possible, will always choose Legacy.