Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.
Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.
The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.
This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.
EDIT: The bootdisk won't work with a recent shim nor a recent grub. The old shim it was using should be revoked if you have any remotely updated machine as well.
TPMs could also prevent attacks like this on your machine.
Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl
Hiberation is not supported in lockdown mode because I'm assuming the kernel (maintainers) expect most people to have an unencrypted swap partition. If you have secured your swap, you can patch [1] the kernel to allow hibernation.
[0] https://github.com/Foxboron/sbctl
[1] https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...
This is false.
The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.
Even if I dislike the UEFI specification and existing implementations, the spec is more than 24 years old. It might fulfill its purpose as a bootloader/OS interface.
The UEFI BDS interface, the one the most people see and the operating system interfaces, is now standardized for many operating systems and OEMs, making it easier to integrate and maintain. It is finally possible to use standard security mechanisms (verified, measured boot) to secure your device. So we can use such technologies to ensure device security reasonably as we do in my corp www.immu.ne
The custom certificate provisioning is a mess and hard to use, but that can be possibly made easy by projects like: https://github.com/Foxboron/sbctl
I don't believe the UEFI interface is beneficial for data-center or embedded devices. The UEFI BDS interface was developed for client platforms and required physical presence. It leads to complexity in the DC and embedded world. I feel a more suitable approach would be www.linuxboot.org which is already used by many Hyperscalers and Embedded companies.
That's my 50 cents about the story. My background, I am coreboot developer and security architect.
https://github.com/Foxboron/sbctl
It should hopefully end up being an improvement on efitools and sbsigntools. Tried posting about this on HN but somehow it's a topic with little to no interest, strange world!
sbctl is essentially a secure boot key manager. It enrolls keys and ensures the relevant files are signed on your system. It works fine and I use it day-to-day these days, but it lacks several nice UX features.
https://github.com/Foxboron/sbctl
The second thing I did was reimplement the UEFI API portion in native Go code from scratch. It currently is feature comparable to sbsigntools, but in pure Go. The top-level API is not completely nailed and It lacks some granularity, but I have written several test tools that replicates the sbsigntools binaries.
https://github.com/Foxboron/goefi
I think more development in these area can help make Secure Boot as accessible as full disk encryption is these days.
https://github.com/Foxboron/goefi
The end goal is to provide better secure boot tooling for people. This is exemplified by my sbctl project which aims to make it silly easy to create keys, and sign stuff. Currently it shells out to sbsigntools, but this feels awkward and I'd enjoy some better integration without having to call out to C-code.