"Something has gone seriously wrong," dual-boot systems warn after Microsoft update (Ars Technica)

I understand that the SBAT variable lives in the EFI data section of the firmware.
And you are correct that in strict sense one it can be seen as not part of firmware because updating it has been standardized to not require support from motherboard manufacturer.

But from users or Linux OS point of view I would still say that we update the BIOS when SBAT is changed because the data lives in the NVRAM chip.

So the security of this system is now in large controlled by a string variable in the source-code that produces the binary?

We've spent decades helping Microsoft to build a walled-garden on UEFI systems ("Oh, but you can turn it off!", uhm, so how do I do so on this ARM tablet I have here?), and now a step of the chain-boot is to verify a.... non-HMAC string?

> I have been running systems without secure boot for decades and I have never been hacked. What exactly am I supposed to be worried about?

This. Is there a clear exploited-in-the-wild path that makes "secure boot" worth the effort and risk?

> I have been running systems without secure boot for decades and I have never been hacked

Are we supposed to base our security decisions on a single anonymous anecdote on the Internet?

The point of secure boot, at a first order of approximation, is to make sure that malware is removable. If something does infect your computer, you want to be able to (ask a technically knowledgeable friend to) boot off a recovery USB stick/CD/etc. and run a malware cleaner or at least wipe and reinstall the OS and recover your files from backup. If you add a layer of security between the firmware and bootloader on one side and the rest of the OS on the other side, and you make sure the attack surface of that layer is relatively small, you can be pretty confident about this.

Secure boot is not intended to protect against remote / network attacks, and it's also not intended to protect against physically-present attackers. It's intended to protect against malware that's already on your device from gaining additional local powers to make itself persistent. So the fact that you haven't been hacked isn't really relevant to whether you run secure boot; secure boot only applies once you've been hacked. And I suspect that the median LWN commenter who has skepticism about security models is unlikely to let consumer-grade malware get onto their system in the first place, for many reasons, including basic awareness that phishing is a thing. (I think this is true even given that said median commenter is much more likely than the median computer user to run random code from not-super-trustworthy sources, in the sense that the median LWN user tends to compile things from source by running a ./configure generated by someone else that they haven't read and understood in its entirety.)

However, the median Windows user very much is likely to let consumer-grade malware get onto their system despite the best efforts of UAC and code signing requirements and all that, and I think it is reasonable for the major Linux distros to consider their median user these days as closer to the median Windows user than the median LWN commenter. So it seems absolutely reasonable for Windows and mostly reasonable for Linux distros to default to setting up secure boot.

(Signatures by themselves are indeed not security, which is why secure boot has always come with a revocation mechanism, and the issue at hand is about invalidating existing bootloaders with valid signatures. On a machine with secure boot, kernel drivers do not have firmware access, so an exploit that gets you code execution in GRUB is actually more meaningful than an exploit that gets you code execution in the booted kernel. While the situation isn't really analogous in either direction, I would say that the fact that the Crowdstrike outage was resolvable by rebooting your machine about ten times to get it to download the un-botched update is an argument that protecting the integrity of the boot process is valuable even when you've lost kernel integrity.)

Initially there were machines on which you couldn't turn it off. And even now, I think that its sole presence is sufficient to encourage software vendors to pressure users to enable it. It just trains users to find it normal to beg microsoft to permit them to use their OS of choice on their hardware, give full-power to some vendors whose software refuses to start without it, fearing that you might have hacked the OS (but if the OS is hacked and allows to run a hacked executable that doesn't perform the check anymore that's probably the same), and doesn't protect against real world attacks that come over the network as "security updates" (cf: the crowdstrike mess which shows how the cybertheater junkies and their lawyers managed to scare enough CISOs to make them run whatever code downloaded from the net in kernel mode on their system).

Overall users are progressively getting used to lose any rights on their hardware. If such a crap had existed 33 years ago, Linux would never had existed in the first place, windows would be mandatory everywhere and everyone would find this normal.