What is an SBAT and why does everyone suddenly care

Original Article ↗ Hacker News Discussion ↗

Microsoft’s rollout of Secure Boot Advanced Targeting (SBAT) updates via Windows Update has blocked booting of older, vulnerable GRUB bootloaders, unintentionally breaking some Linux dual‑boot systems. Commenters weigh the trade‑offs between stronger protection against real bootkit threats (like BlackLotus) and the risks of letting Microsoft-controlled keys and revocation lists affect non‑Windows operating systems. The conversation broadens into critiques of Secure Boot, TPMs, and opaque error messages, alongside practical advice on key management, custom signing, and when it may be simpler to disable Secure Boot altogether.

Impact of SBAT Update on Dual-Boot Systems

  • Windows Update pushed an SBAT policy that revokes vulnerable GRUB versions to block Secure Boot bypasses (e.g., bootkits).
  • Intended behavior: only enforce on “Windows-only” systems and let Linux distros update GRUB/SBAT themselves.
  • In practice, many dual-boot systems were broken:
    • Windows kept booting; Linux GRUB/shim would fail under Secure Boot.
    • Some systems booted via the UEFI removable media path or had no clear non-Windows BootXXXX entry, so Microsoft’s dual‑boot detection likely misclassified them.
  • Fixes discussed:
    • Temporarily disable Secure Boot, boot Linux, update GRUB/shim/SBAT, then re‑enable.
    • Manually mount the EFI partition from Windows and replace the GRUB/shim binary.
    • In extreme cases, reset UEFI variables/CMOS to restore defaults.

Error Messages, Diagnostics, and UX

  • Many complain Secure Boot/shim errors are opaque (“something failed”) and don’t say what or how to fix it.
  • Desire for:
    • Specific error codes and causes.
    • On-screen guidance or URLs/QR codes (though some object due to link rot and maintenance burden).
  • Shim has a verbosity EFI variable (toggled via tools like mokutil), but few users know it exists.
  • Broader frustration with vague errors across OSes (Windows update codes, “invalid parameter” messages, boot hangs with no cause).

Secure Boot, TPM, and Threat Models

  • Split views:
    • Pro: Secure Boot + TPM meaningfully raise the bar against bootkits and FDE credential theft, and are useful for fleets of managed machines.
    • Skeptical: Closed firmware, potential backdoors, and user lock‑out risks make Secure Boot feel more like vendor/DRM control than user security.
  • Some argue that disabling Secure Boot or using legacy/CSM boot is simpler and “good enough” for most; others want a full chain of trust for travel or high‑risk scenarios.
  • TPM‑backed disk decryption (via Clevis, systemd-cryptenroll, etc.) is seen as powerful but adds reliance on opaque hardware; several recommend always having a strong passphrase fallback.

Microsoft’s Role and “Social Contract”

  • One view: Microsoft reasonably blocked a known-exploitable boot chain and even waited years, expecting distros to update.
  • Opposing view: Allowing a Windows update to unilaterally break Linux boots on user hardware crosses a line, reinforces dependency on Microsoft’s keys, and validates long‑standing concerns about Secure Boot power asymmetry.
  • General agreement that Linux distros also bear responsibility for shipping patched GRUB with proper SBAT “security generations.”