Matthew GarrettLooking at the reports of some systems failing to boot after the latest UEFI DBX update and wondering whether it's another case of https://mjg59.dreamwidth.org/22855.html
We ended up writing some hilariously crappy workarounds for Linux to prevent this kind of thing, where firmware fails to boot if the UEFI variable store is too full. We check whether the write would leave under 5KB of free space (as reported by the firmware), and refuse the write if it would. Easy! Except some firmware would never actually increase the available space count if a variable was deleted, so after a while we'd just never be able to write any more variables
I can't remember how I figured this out, but the affected machines would trigger garbage collection if we tried to create a variable bigger than the available space, so Linux just tries to create a giant variable and then deletes it again to force the firmware to actually update the free space counter
Fucking computers, man
Cassandrich@mjg59 Fucking UEFI. The ring -1 (or is it -42 now? does anyone even know or care?) shit nobody asked for.
Demi Marie Obenour@alwayscurious @mjg59 Device tree solves that problem. UEFI and ACPI both address a much larger-scope problem (which a lot of us don't want) of having a persistent layer under your trusted OS that you also have to trust, that continues execution after control was supposed to be passed to the OS, and that the OS is forced to interact with to access important functionality.
@dalias @mjg59 If there was a way to force vendors to upstream all of their board support code, then device tree would be just as good as UEFI + ACPI for portability, but right now there is no such way.
I fully agree that UEFI + ACPI are security disasters and that device tree is much better in that regard, but it is also one of the reasons that one can boot Linux on x86 systems that were never intended to run it and usually have a lot of stuff work out of the box without someone having to write drivers first. I'm not aware of good solutions that are also economically feasible in the present market and regulatory environment.
@alwayscurious @dalias device tree fundamentally doesn't solve the "I want to boot an install image from last year on a device using a thermal sensor released this year" problem, and no amount of upstreaming changes that
@mjg59 @alwayscurious It does if your thermal sensor driver is independent and not baked into the kernel.
@alwayscurious @mjg59 You don't need the "install image". You setup the root fs media via an existing machine and install it in the target device ready to go.