the amount of knowledge about UEFI and secure boot is so low among so many people who are otherwise really knowledgeable about computers (and even specifically firmware) is kinda sad
UEFI is really cool! we have drivers, a shell, standardized networking, menus that let you pick specific files to boot. your os can control your boot device and automatically enroll custom secure boot keys with a single click. it's so cool and i still have to convince people that your bootloader not needing to enable the a20 gate is a good thing, actually

@puppygirlhornypost2 @doskel there's one thing they left out in all of that
i'm blind
there are no screen readers or at least self voiceing menues of any form
people tout how good uefi is but if you can't even access the menu how ar you ment to say turn off secure boot or change your usb boot order?
should screen readers or self voiceing menues ever hit uefi, only then will i strongly go hole hog in it's usage.

@doskel you can also run uefi applications that aren't whole ass OSes either! and they can do networking and disk shenanigans too!

@astrid I FUCKING LOVE IPXE.EFI

@mhussain @puppygirlhornypost2 i mean i take your point but BIOS lacks the same things unless you redirect to a serial device or do evil vendor hacks, but... UEFI can do the same? arguably efi is better there because you can change boot order from inside your OS, letting you use all your ordinary accessibility tools

@doskel where can i learn more about it

@m i don't know why i didn't mention it but i think that is the biggest issue lmao
where do you learn about UEFI? idk, go read the UEFI specification? drop to an efi shell and cry for a few hours?

the efi spec is probably the best place to start (It's surprisingly digestible and friendly) but that's a shit answer either way. maybe I'll go cook something up.

@doskel the problem is that Windows and Linux were designed around BIOS. that’s the problem

@eri what
what does this mean. what BIOS am i loading when i launch Linux on openfirmware. where is the BIOS that windows NT uses for PowerPC or itanium. this is a comical argument given Linux ditches bios calls the millisecond it can, and if you stub load the kernel you don't touch the BIOS for a single instruction with the CSM off.

@doskel UEFI is cool but it should have been OpenFirmware

@izzy okay this is the only good anti-efi take
bring me my Forth

@doskel it's "fine, i guess" but has undesired behaviors imo

- switching disks can put network boot above the newly inserted disk (because it doesn't treat "boot from HDD port 1" as a boot option and select order within the disk, but registers each item in the disk individually)
- i've gotten into a corrupted mode where no boot entries were visible and registering systemd-boot made it vanish upon reboot, had to clear CMOS to escape it
- and yet it doesn't fix the issue where Windows and Linux fight over being the primary boot entry

@nyanpasu64 these are fair but mostly the result of Vendors. vendors are the Antichrist and will ruin everything, but I've been lucky enough to mostly get decent implementations that don't have those major breaking bugs
shuffling of boot order can be annoying but I've been able to configure it to be static, or just use systemd-boot tricks to always set the boot order
and for windows and linux fighting
well. that is misery but it's still better than multiboot on BIOS :p

@doskel when i learned about it, i was disgusted that EFI executables are PE executables, hacked on top of the MS-DOS MZ format. The GPT partition table uses mixed-endian UUIDs (probably compat with Windows 3.11) and the FAT file system (which you kinda have to use, also MS-DOS) with the ugly af BPD header format with twelve incompatible versions and floppy disk geometry indication. ESP literally still have a sectors per track count.

Incredible legacy cruft for a "modern" system.

@Nero yeahhh it's definitely not. Great. it's a bit shit. as someone else mentioned, open firmware should've made it to x86. alas, though, for the x86 world, UEFI is all we get, and a massive improvement over legacy BIOS no matter how rough it still is

@doskel in that all the tools around how a conventional desktop/server is set up are designed around the assumption that the bootloader is dumb and annoying and terrible so you should get it out of the way as quickly as possible. it never takes advantage of any actual features of UEFI because those features were assumed to never exist. developers assume treating the bootloader as a dumb tiny stub is the only way anything could ever happen forever because it’s the way we’ve always done it.

also there’s the fact that the raspberry pi doesn’t use it, and every non-x86 linux device clones the raspberry pi to a degree. so relying on UEFI locks you out of the whole embedded world, which is a very relevant place given how expensive hardware is these days

@eri i find myself able to do quite a lot with efi? LVFS automatically reconfigures the efi boot order to load a different executable, i have my gentoo installkernel setup to automatically select the new kernel as a boot option while leaving two old versions intact, systemd-tpm does magic with the TPM to make sure my system hasn't been tampered with, and systemd-sbctl automatically enrolled my keys and signs my kernels to let me use secure boot.
i don't really have a traditional bootloader anymore. i load a UKI and I'm immediately into the OS from firmware. I've known people who managed to hack a BTRFS driver into their UEFI image so they didn't even need a dedicated efi system partition.
and for the embedded world... I guess you have a point? but really you're going to be locked out of the embedded world anyway without a lot of concentrated effort because of the disaster that is device discovery there, so i figure that point isn't terribly relevant. hell I'm of the opinion that arm should probably not use UEFI, because it's not a great design on the whole, my general argument is just that for the time being where we're stuck on x86, we would do well to take advantage of UEFI rather than just loading grub or even sticking to legacy BIOS

@doskel @puppygirlhornypost2 you can change your boot order from inside your os?
doo tell more?
from in windows 11 arm64 for exammple i've not found this setting
can you give details?

@mhussain @puppygirlhornypost2 oh, here's news to me: windows doesn't actually let you fully interface with UEFI, so that's largely moot... I'm far too embedded in the Linux world with tools like efibootmgr. my apologies for that, I should've checked the state of the efi on windows

@doskel @puppygirlhornypost2 see i would run linux on here butt the dtb required for my acer aspire 14 ai snapdragon is not created

@mhussain agh, yeah the arm64 situation sure is. exciting, in a way. and uefi on arm feels really weird anyway, you have the chance to get a properly clean and fresh firmware stack and you choose the itanium solution?

@doskel @mhussain arm is not free from the horrors of x86 and it's quite sad

@doskel I prefer coreboot loading linux directly. no need for a second implementation of all the drivers just for the boot firmware when you can just use linux/kexec as a bootloader

@doskel By "enroll custom secureboot keys" do you mean add them to MOK? I don't think any UEFI implementation lets you easily take proper ownership of the PK.
Many vendor PKs are frankly mishandled and in some cases lost entirely. MSFT 2011 UEFI CA Cert has signed some things it should not have and there are questionable signed shims floating around.
The whole design has major security holes needed after the fact redesign (SBAT) to deal with, eg, black lotus.
Secureboot is a lot of theater..

@amy okay so I'm not tremendously confident in this BUT
at least on my desktop (Asus b450f thing) and laptop (framework 13), i have been able to remove Microsoft keys to the extent that it doesn't show anything other than my keys in the key viewer and is unable to boot windows due to a secure boot violation
that said, in some cases i know you have to install certain vendor keys to get graphics or disks working, but I've not had that myself

@doskel None of this applies in cloud environments though, where there are simple APIs to manipulate and control UEFI vars. There's nothing wrong with the key hierarchy itself, it's just incredibly painful to manipulate it on real machines.

@noisytoot tis the dream, but for where we are at present it's not a very accessible option for most cases

@noisytoot @doskel what if I ever want to boot something else

@lily @doskel kexec supports multiboot, I managed to load seabios that way (in a VM, I haven't tested that on real hardware yet)

@noisytoot @doskel can it chainload uefi
I hate MBR booting

@lily @doskel you could probably load EDK2 or u-boot that way too, I just haven't tried

@amy okay i remember one of the catches here: in order to make my gpu work, i had to either sign its firmware hash, or enroll the Microsoft key, and the former option is still kinda jank and not fully supported

you can also just say "fuck it" and use the bios option ROM from the video card, which loads unsigned because this motherboard is. funny.

@doskel Yeah it's just.. like the whole management bit is not really set up well. PK enrollment is not simple, and OS vendors don't publish KEKs or DB/X updates in an easily consumable way (ubuntu is the exception).
Like taking control is one thing but are you capable of revoking compromised keys if your OS vendor lost one? How would they even publish it? Do they publish their SBAT level? Often people just sign the 2011 UEFI CA anyway which entails trusting absurd amounts of random shims.

@amy I found pk enrollment to be pretty nice? i just reset keys to put it into setup mode, and ran sbctl enroll and it all just Worked immediately. as for vendor revocation updates, i get them through LVFS on my desktop and laptop when theyre using stock keys, without any config

and i mean for your OS vendor losing keys, that's an issue, but it's so easy and well-supported to just sign with your own keys that i think that's probably a reasonable default now

@doskel The LVFS updates are nice, though they're often kind of out of date because vendors are usually coordinating on SBAT levels and don't publish DBX updates of sbat for a long time to avoid locking each others users out.
Not that secureboot is nothing, but it's far less secure in reality than it seems even if you take control of the PK.

@amy i do take the point that it's definitely not perfect, and when vendors fuck up boot guard or whatever it's just moot anyway, but it's worth a lot more than people tend to give it credit for and a lot easier to use than most people expect