Correct me if I'm wrong but SBAT isn't used by the Microsoft Windows bootloader itself, instead they use a separate variable storing a Secure Version Number (SVN) which gets incremented from here on out each time Windows deploys a replacement bootloader. This is a new thing they introduced in July 2024 though and only if you manually enable it (because MS tied it in with a signing CA change and revocation) so I suspect most don't have it. This means if one wanted to prevent Windows booting in an easily reversible manner, they could revoke the old production bootloader signing CA from 2011 and then increment the SVN to something unrealistically high in value. This would in theory cause Microsoft's new bootloader to always refuse to boot without needing to revoke the CA.
In terms of the inverse, I believe Microsoft writes changes to the SBAT using two registry values located here: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT
UpdateStatus presumably controls if the variable has been changed yet and SbatLevel contains the raw data to be written.
The one which contains the payload is SbatLevel and I'm guessing that writing something like the following would make it so that shim will always refuse to boot:
sbat,94,2036060100 shim,95 grub,93 grub.debian,92
I must commend both Microsoft and the community which worked on SBAT (and which probably inspired MS to implement SVN) as both SVN and SBAT are reasonable compromises to bring the chain of trust for Windows and Linux slightly closer to what Apple has done with their more recent security enhancements. It's not perfect but it does very much raise the bar without compromising on our freedom to tinker.
Re: Why is it up to Microsoft to take care of MY computer's security?
In terms of the inverse, I believe Microsoft writes changes to the SBAT using two registry values located here: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT
UpdateStatus presumably controls if the variable has been changed yet and SbatLevel contains the raw data to be written.
The one which contains the payload is SbatLevel and I'm guessing that writing something like the following would make it so that shim will always refuse to boot:
sbat,94,2036060100
shim,95
grub,93
grub.debian,92
I must commend both Microsoft and the community which worked on SBAT (and which probably inspired MS to implement SVN) as both SVN and SBAT are reasonable compromises to bring the chain of trust for Windows and Linux slightly closer to what Apple has done with their more recent security enhancements. It's not perfect but it does very much raise the bar without compromising on our freedom to tinker.