What is an SBAT and why does everyone suddenly care

The alternative dystopia is one where the NSA can grab your laptop, rip out the storage, write some code into the boot chain, put the storage back, leave, and you have no evidence to know who did that.

Signed code fixes this by requiring someone actually put their name to the code. If it's not someone I recognize, I don't boot. And yes, the NSA could theoretically compromise a signing key with a $5 wrench. But then they blow their cover. Signatures create a paper trail that makes plausible deniability vaporize.

I guess in their defense the same attack can be used against any other OS so they're unintentionally protecting Linux as well, since they stated this was supposed to be a Windows-only system change. You can disable secure boot if you don't want to be secure. And, there is a way to disable the SBAT policy and keep secure boot if you want that, which is also insecure. Disable Secure Boot, login, sudo mokutil --set-sbat-policy delete, reboot again, re-enable secure boot. But, then you're susceptible to the attack.

I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all.

Who is Microsoft to decide what others do on their machines?

That would be an amazing rant had it only ended with "Sent from my iPhone".

Since the Blaster worm incident two decades ago, we're in a new era where security at scale becomes the forefront responsibility of the companies developing the product. That includes writing more secure code, having more verifications in place, adopting more secure technologies, but also, limiting user capabilities in order to avoid at scale security incidents.

This isn't about Microsoft. Some of these "forced" limitations are: UAC (User Access Control)/SUDO, Bitlocker/Full disk encryption, App sandboxing/On-demand permissions, Signed firmware and boot mechanisms, signed release binaries, Jailbreak-protections, Limitations on raw packet operations, auto-installed updates, forced security updates, closed source code, built-in anti-malware.

When you have a billion devices running around the world, you can't say "hey we'll let this arbitrary group of billion people do what they think is best for them", because you then end up with Blaster worm, and the whole Earth falls apart.

Think about the more recent CrowdStrike incident. That kind of deployment has been performed by professionals, not even regular people, and yet, it's managed to bring down the entire world to its knees. People might have died because of CrowdStrike.

CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. Now, people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen. Yes, some users who want to install their precious kernel driver could have problems, but at least the world would keep running.

Microsoft is nowhere to be blamed about this. Secure defaults is the responsibility of every product that intends to be used at scale.

If you'd like, you can disable Secure Boot, keep your data in plaintext on your hard drive, let all applications run as root, and you'd be the most powerful user in the universe. I'm all for personal freedom to disable the security features, but, at scale defaults must always prefer security over capability. That's not about Microsoft, or Google, or Apple. That's about at scale risk management.

At the time of opening this page this was the top-ranked comment and that is a bit depressing. If you read Matthew Garrett's blog in full, you can learn quite a lot about what went into the process of building out secure boot for Linux.

* 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.

I agree with everything except this:

Things like TPM and "secure" boot were never envisioned for the interests of the user.

I am successfully using TPM with coreboot and Heads, with my own keys, to protect against boot attacks on my Librem 14 with Qubes OS.

Seems to be a general trend in a lot of software nowadays. Vague error messages telling you "Something went wrong" with no additional details.

Or at least include a URL to a web page explaining the error and what you can do about it

shim has an EFI variable to control its verbosity, you can set it to output all the gory details with e.g. `mokutil --set-verbosity true`, and on a glance there are some tools on Windows too to modify EFI vars

If security vendors followed this logic then all an attacker would have to do is look up the error and render the security moot.

By leaving the reason vague an attacker has no immediate feedback and no clue how to remedy.

I vastly prefer the way this works now.

I hate error messages from most software. Recently my system failed to boot because systemd told me a start job is running for a certain disk. And it doesn't tell me what the nature of the start job is, why the start job is needed, and why the start job is not finishing. From the disk UUID I could guess the first two, but there was no way to guess the third.

I hate to say it but the best way to use windows is to install it, fully update it, nuke the update center, obliterate the update services and leave just defender updates enabled. Then when it's too out of date in a few years, reinstall and repeat.

The result is a rock solid reliable experience that even an LTS linux can't match. Nothing ever breaks, every new piece of software works since it's all mostly self contained, backwards compatible, and not dependent on 13543 dynamic apt deps that all need to be at a specific version. I thought flatpak would fix this on linux, but every time I flatpak itself updates half of its apps break with mysterious error messages and refuse to launch until they're also updated. It's a pretty shit execution what could've been a great windows equivalent. Okay? Okay. Rant over.

My Windows install is stuck in a boot loop like this - it spends 10 minutes trying to update and then fails, except maybe 1/3 times it then boots normally. I don't even try to do anything about it, I just marvel at it.

The last time I had to manages windows I used Unattended to wipe and re-install to a base level. I found that diagnosing and troubleshooting was not worth the effort.

https://tgup.net/

tweak QEMU for performance and passthrough Any guide you could link to that covers all of this? I would like to setup a very performant windows VM.

Ubuntu regularly locks up and black screens when I try to sleep/hibernate. It's a very common problem that has nothing to do with Windows or Microsoft. I also have had 0 issues with dual booting for roughly 10 years now. HN wouldn't be HN without some baseless MS bashing.

When it comes to the realities of dual-booting

The sad and depressing part is that along the way we lost all possibilities of running coreboot or libreboot as an open alternative.

The only real option is to buy a used laptop from before the T44x generation (if you really want it secure)... or newer machines that come with other perks like soldered-on batteries that destroy the mainboard along with them when they leak out eventually.

I am not sure what the consumer rights protection agencies on the planet are doing, but seemingly they've been asleep at the wheel for way too long now.

(Tinfoil hat) (...) I think part of the reason MS is enforcing TPM2.0 and now this SBAT update is that there is widespread rootkit level malware and they are trying to stay ahead of the curve.

The only vendors that seem to do something against it are somewhat System76, Frame.Work, Purism and maybe Starlabs. But the huge majority of devices is under the absolute control of Microsoft's signing process now. So I would argue that this isn't a tinfoil conspiracy, but a strategical decision that MS made to re-grab their lost power on x86 systems.

widespread rootkit level malware and they are trying to stay ahead of the curve

Microsoft is within US-legislation. So a three-letter agency already has the keys and their spyware is a signed UEFI module.

It would be entirely unsurprising if most TPMs had a clipper chip[0] like backdoor.

[0] https://en.wikipedia.org/wiki/Clipper_chip

[...] there is widespread rootkit level malware and they are trying to stay ahead of the curve.

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.

hibernate always have been more trouble than it's worth. and specially now when boots takes less time than loading your webmail.

it just screams you have no data hygiene. it's the extra step after living years with 723 open tabs.

qemu passtrhu is the way. and if you don't own expensive hardware (i.e. only integrated graphics like all feasible laptops), just dual boot with your own signing keys so you don't have yo worry about revocation crap. either its signed or not. revocation is just replacing the root PK keys.

I installed Linux on a new laptop yesterday, and couldn't get either NixOS or Debian to install until I turned off secure boot. So I guess these distros don't bother getting every release signed by Microsoft.

At least it was easy to turn off. I just wish the error message mentioned Secure Boot -- it took me a few minutes to figure out what was wrong. At first I thought I had a corrupt USB stick or something.

You could if you want to, but if your distribution provides a UEFI bootloader (shim / grub / systemd-boot / whatever) signed by the default MS-trusted cert, or you're willing to set up everything yourself with your own certs, it doesn't hurt to enable it either (except when an incident like this happens).

Depends on the distro, Fedora for example works with secureboot enabled.

If you are using Nvidia graphics you have to deal with signing the kernel drivers but it is pretty easy, AMD or Intel works out of the box.

This has been my stance for years, but I am open to be persuaded why this is a terrible practice that will lead to kitten murder.

I saw someone else give a similar reasoning that if there were a booting error, they would never assume it was a rootkit, but some breakage between all of the booting cruft. I certainly lack any expertise to understand what happens during boot to be able to diagnose problems.

Most mainstream distros work fine with secure boot still enabled. You can disable it if you want, but if you use Bitlocker, disabling secure boot will require you to enter the recovery key, which is a massive pain.

You can always disable secure boot if you want to, but in this case installing the patches released two years ago would probably be a better fix.

Sure is if you want to hibernate!

This feels like a "my secure compartments are all connected together" moment. If Microsoft want to verify that they're in an all-Microsoft boot chain, sure, whatever, fine. But somehow the compromise of any loader allows compromise of Windows?

Exactly how would you propose starting software securely from an unknown environment?

Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss

So does a password and encryption.

It was never designed to Empower the (end) User.

This is vaguely the experience that should have been present in an Empowered User centric BIOS.

First cold boot; BIOS verifies the hardware isn't broken, checks for a boot preference, finds none.

Present the User with a set of choices: Check for BIOS Updates (manufacturer), Check for OS Choices (manufacturer), Begin installing an OS (options list). Locally cached (present with the system) choices would be listed first. Microsoft Windows (installer) is probably OEM shipped (might not be). Linux / DistroName plugged in USB device, etc... 'Local Network boot (search)', and 'Install from the Internet' (shipped by manufacturer or added by local preference).

The BIOS would also support enrolling ANY signing keys of local preference with user confirmation. This should happen even at first boot for the keys known by the manufacturer; they shouldn't just be in there for free, confirming the key with the user should be part of the flow.

The BIOS _MUST_ also support multiple bootable entries, even if one is the default (without a timeout, even with only manual selection E.G. F12 / F11 / whatever... though this too should be standardized).

I have seen recommendations to not dual boot with non-obsolete Windows, because its updates would have a high risk of screwing up grub, but instead give that Windows it's own hard drive, and boot it 'manually', by selecting the boot drive at startup in the 'BIOS'. Sounds like that was good advice ?

I do something similar on all my laptops:

- have custom secure boot platform key

- use a unified kernel image (UKI) which means I directly boot the kernel from efi (and place it in the efi partition)

- sign the image with that platform key (I use sbctrl)

- have every thing else including swap partition for hybernation fully disk encrypted, I could set it up to auto unlock using TPM2 but I would recommend using a long password. TPM2+password would be optimal. There had been too many cases of leaky TPMs and especially on a laptop you don't want to fully rely on it (through you in turn could decide to auto login if PCRs are unchanged, or login using only the (often not so secure) fingerprint reader etc.)

- efi password, I mean if you don't set that you lose most secure boot benefits... EDIT: Not really most, there is still a bunch of ways it helps but it's anyway a bad idea to rely on secure boot and not have a efi password

As bonus tip:

- include the vfat in your initramfs (i.e. `MODULES=(vfat)` in `/etc/mkinitcpio.conf`) if your booting kernel and installed kernel modules ever mismatch that is nice to have to fix the issue

The "new" way of doing this would be using systemd-cryptenroll [0]. I did this recently on Ubuntu 24.04. I actually tried the default LUKS+TPM shipped with Ubuntu 24.04 at first [1], but it was a bit disappointing because it locks you into using snap-based kernels. This means you cannot install custom DKMS modules (which I needed). Although Clevis is very interesting software (you can even unlock based on some other computer in your network [2]), it's not absolutely required anymore for LUKS+TPM.

[0] https://fedoramagazine.org/use-systemd-cryptenroll-with-fido...

[1] https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-c...

[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_...

MS has zero vested interest in caring. If they brake booting for Linux users, how does that hurt them in any meaningful way? Sure they get some press, but is it bad press if most people are never affected by this?

People that dualboot are probably also people that run random debloat scripts that disable telemetry. So when such system broke there was no signal it happened.

Microsoft's bootloader is clearly intended to be a pain in the ass. There is nothing new about this situation. They have been doing it since the 90s when any windows update would write over your MBR without a care in the world. We all hoped that UEFI boot menus would resolve the situation. They would have, if only Microsoft were willing to stop intentionally polluting everyone's partitions. Instead, it is not only the default, but the only option, for the windows installer to squat in the first EFI System Partition it sees. That means that if you install linux first and windows second, windows will install its bootloader to your ESP. Even if it's too small. There is no way to disable this behavior. It's asinine.

P.S. The ultimate irony of this situation is that it actually ends up breaking concurrent windows installs more often than anything else.

From the people reporting this affecting their Linux boots in various IRC/Matrix forums and my diagnostics with them, very often they weren't dual-booting in the Microsoft sense, in that they were booting using the UEFI Removable Media Path so there was no entry in the motherboard firmware's Boot menu.

I suspect the MS installer simply scans the EFI BootXXXX entries and looks for a non-Windows boot-loader path like, for example, /EFI/$distro/shimx64.efi

If one-such doesn't exist the installer likely assumes it is not a dual-boot system.

I don't see why you couldn't update grub from Windows, its just EFI binary in ESP after all.

I wouldn't try update grub from Windows, but the second strategy would work.

TLAs from major powers probably have backdoors in your UEFI, mainboard or OS. But even if they do that doesn't mean they will use them on everyone, they probably keep the good stuff for the most valuable cases. Each use of an attack carries the risk of the attack vector being discovered and prevented in the future. And besides, there are threat actors besides TLAs of the USA, Russia and China.

If you use full disk encryption secure boot is pretty essential, otherwise an attacker can modify the code that asks for your credentials to also log them somewhere easily accessible, circumventing your entire encryption. If you don't do full disk encryption it's still a decent protection against some bootkits.

It can absolutely be more trouble than it's worth. It's not that useful in most desktop computers. But if you are traveling with a laptop it's probably worth some effort to keep secure boot working on that system (and make it more difficult to disable)

I've been using 'secure boot' with Debian for a while now. They use a signed first-stage boot loader that allows booting the OS.

I have similar doubts on whether my system is significantly more secure as a result of using it.

agree its a waste of time, but we pay the paranoid cost is special occasion. it does make breaking FDE just a little bit more annoying/expensive.

the only time it's worth the hassle for we to enable it: travel to the USA, Russia and most of africa (if the country have USA backed airport security, like uganda). pause updates, enable secure boot with a disposable key we don't store anywhere. that on top of the usual FDE with plausible deniability dual boot.

but we still prefer to just fly contributors with blank devices if we can.

Or does installing Windows contaminate the TPM module permanently?

It's not the TPM, it's a simple UEFI variable. AFAIK, there's a way in the BIOS to reset all these variables to their original default value, though you might have to use the "clear CMOS" jumper to do it.

I agree, this is the key question. It seems like all the distros, and microsoft, need to coordinate on the "security generation", whenever grub (or other linux boot component) releases an update or patch? Maybe that's an extra annoyance they didn't have before, so until now they just left that number alone, and kinda forgot about it?

Major question for me is, are the grubs that are getting rejected completely unpatched, or were they patched by distros without updating the "security generation"?

Reading into https://www.gnu.org/software/grub/manual/grub/html_node/Secu...

It's possible it's both?

I'd be also really curious to hear how MS was attempting to do dual-boot detection

I'm in the boat that they shouldn't doing dual boot detection at all, it sounds like everyone agreed to use SBAT to stop vulnerable bootchains from being exploitable and some Linux distributions got caught slacking.

Thank you. I had a similar problem in Firefox 129.0.2 on Linux.

agree; defined long acronym immediately in article.

i'll probably read the test, but that's some high quality posting from the get-go!

It goes the other way too. An Ubuntu Update could put the Windows bootloader on the deny list.

That's why you wait a while before raising the SBAT requirements, so both of your distros can be updated. Microsoft waited two years, for instance.

Yah, I got hit by this as well. Was pulling some stuff off of windows, it updated overnight, rebooted, and I woke up to my default Ubuntu boot being horked. A bit of a WTF till I started searching for it. I'll be backing up and leaving that box as Linux + a vm.