Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

Original Article ↗ Hacker News Discussion ↗

A regression introduced in Linux kernel 6.9 meant that, for over two years, systems using LUKS’s `luksSuspend` feature could appear to lock encrypted disks on suspend while secretly leaving the decryption key in RAM. Commenters examine how this undermines cold-boot protections for users who rely on suspend‑to‑RAM for security, contrast it with hibernation and TPM‑based or hardware memory encryption approaches, and debate what realistic threat models look like for ordinary users versus high‑value targets. The incident also prompts broader criticism of testing, invariants, and auditability in large C codebases, along with comparisons to proprietary solutions like BitLocker and FileVault.

Nature of the regression

  • Since Linux 6.9, cryptsetup luksSuspend no longer reliably wiped LUKS volume keys from RAM on suspend, even though users were still prompted for their passphrase on resume.
  • The bug stemmed from a kernel keyring lifetime change: keys stored in a thread keyring were expected to vanish when the thread exited, but stopped doing so, leaving an extra copy of the volume key in kernel memory.
  • This made systems that thought they were “extra secure on suspend” less secure than intended, while appearing to work normally.

Suspend vs hibernate and threat model

  • Suspend-to-RAM: RAM (including disk keys) stays powered; most systems don’t clear LUKS keys, so disk encryption primarily protects powered-off or removed disks.
  • Hibernate-to-disk: RAM contents (including keys) are written to an encrypted swap/image and RAM is powered off; on resume, users re-enter passphrases.
  • Some argue that only hibernate (or always powering off) meaningfully protects against cold-boot attacks; others note attack practicality depends heavily on threat model.

Cold boot and physical access

  • With physical access to a suspended, locked laptop, attackers can:
    • Perform cold-boot attacks (rapid reboot into a custom OS, or RAM freezing and transfer).
    • Use DMA or similar techniques on poorly configured systems.
  • Several comments stress this is mainly relevant for high-value or state-level targets, not typical thieves.

Workarounds and mitigations

  • Recommended mitigations discussed:
    • Use hibernation instead of suspend; some Fedora users auto-hibernate after a suspend timeout.
    • Enable CPU memory encryption (Intel/AMD features) where available, though this mainly counters physical RAM attacks, not logical misuse of keys.
    • Use EFI/TPM features like MemoryOverwriteRequest to ensure RAM is wiped on reboot.

Scope and distro specifics

  • luksSuspend is upstream in cryptsetup; Debian added integration that ties it into suspend, and this approach was reportedly ported to other distros.
  • The regression affected configurations relying on luksSuspend semantics, not stock “just suspend” setups.

Comparisons and broader security themes

  • Long digression comparing BitLocker, FileVault, LUKS, and VeraCrypt:
    • Enterprises like BitLocker’s manageability, especially with TPM+PIN and key escrow.
    • Privacy-minded users are wary of proprietary encryption and cloud key escrow.
  • Several comments highlight:
    • Open source is more auditable but not automatically audited.
    • Lack of robust integration tests allowed this regression; adding a dedicated test is seen as the real long-term fix.