What is an SBAT and why does everyone suddenly care

Original Article ↗ Hacker News Discussion ↗

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