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

Original Article ↗ Hacker News Discussion ↗

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.