What is an SBAT and why does everyone suddenly care

* The UEFI Consortium via their spec mandates nothing, but Microsoft (not mentioned here, but to stick Windows stickers on your boxes and get WHQL for your hardware) requires carrying their db keys: https://mjg59.dreamwidth.org/9844.html

* You can take control of the process yourself and evict Microsoft's keys: https://mjg59.dreamwidth.org/16280.html the details are sort of in here, but let me summarize it for you: by default the platform key is provided by your manufacturer, which signs a key-signing-key, which itself signs updates to the DB (what you can boot) and DBX (what won't boot even with valid signatures). As the article says, x86 specifications explicitly require that this database be modifiable, so you can always install your own keys. I did this for a while, and on my laptop I evicted Microsoft's keys entirely. Ultimately you can bypass this if you can bypass the BIOS password simply by resetting the database or disabling secure boot and... well, https://bios-pw.org/ .

* The whole thing was built so that you can re-sign your own kernels and other bits if you want (you could just sign your distribution's db keys with your KEK, which will make OS upgrades smoother): https://mjg59.dreamwidth.org/12368.html

* Here is an article on secure versus restricted boot: https://mjg59.dreamwidth.org/23817.html - I said above that the x86 specifications explicitly allow the key database to be modified (Microsoft's ARM devices were the inverse).

Now some non-Garrett points:

* To be affected by Windows Update, you need to run Windows. Tautological and true!

* If you update your firmware via, say, LVFS (https://fwupd.org/) and your distribution via its standard tools you get updates to things like dbx all the time. All from your hardware vendor and friendly FOSS folk, no Microsoft involved. You might even be using SBAT right now.

* Those Talos II boards people like? They also have secure boot. It is entirely optional and since Microsoft only implemented a "kinda" version of NT for PowerPC, they're definitely not involved. It is not UEFI, since there's no UEFI for POWER (there is for ARM and RISCV though). You also aren't getting anything from LVFS and barely anything from your distro, but, secure boot is there. You can turn it on.

Personally, providing I can control the keys and decide what is and is not trusted and whether I use it, I am fine with it. Depending on what you want to achieve, secure boot is not always unreasonable, and neither are TPMs - small example, software exploits won't be able to successfully modify the boot chain if you have good key management (i.e. you sign elsewhere). They also have their limitations - as usual, physical access is hard to defend against and remote attestation is a hard problem all around.

There literally is. BlackLotus bootkit actively abuses a vulnerability Microsoft has been trying to patch (by updating the blacklist the vulnerable bootloaders) for the past two years and it's still ongoing AFAIK.

Targeted attacks against individuals or small groups from state actors are basically impossible to protect against. Widespread compromises of all operating systems at the boot level should be fought against.

I don't really think malice explains Grub being limited b/c of Microsoft's software at the boot level. There's conflicting objectives at play, and that will inevitably produce, well, conflicts.