FR
live

TPM patches lift Linux lockdown’s long-standing hibernation ban

Linux’s lockdown mode, enabled by Secure Boot, has blocked hibernation since its introduction because the memory image written to disk cannot be authenticated. A patch series from Matthew Garrett proposes signing that image with the TPM to reconcile security and suspend-to-disk.

A closed laptop resting on a dark desk, one amber power LED glowing.

9 October 2026. Matthew Garrett, a kernel developer at NVIDIA, posts a request for comments (RFC) for patches that would allow hibernation while the Linux kernel runs in lockdown mode. 9 October 2026. Phoronix covers the story, bylined by Michael Larabel. The issue, settled years ago, is simple: a system booted with Secure Boot enters lockdown, and lockdown forbids hibernation. Why it matters: millions of Linux laptops must today choose between verified boot security and suspend-to-disk — the patches propose that they no longer have to.

What lockdown forbids, and why

The kernel’s lockdown mode restricts two things: the ability to modify the running kernel image, and the ability to leak kernel memory. It engages automatically when the machine boots through UEFI Secure Boot, but an administrator can also enable it manually. In practice it closes interfaces such as /dev/mem, /dev/kmem or loading unsigned modules — all paths through which a privileged process could compromise the kernel’s integrity.

Hibernation is one of the collateral victims, and that is not an oversight. Hibernating means writing the contents of RAM to disk, then reading it back from disk on resume. The kernel, in its current form, has no way to guarantee the image was not tampered with between suspend and resume. An attacker with access to the disk — or the swap device — can modify that image to inject code into the kernel at resume, or simply read the sensitive memory it holds.

That is exactly the scenario lockdown exists to prevent. Allowing unauthenticated hibernation would reopen, through the suspend-to-disk door, the hole that lockdown had just closed. Hence the blanket ban: conservative, but frustrating.

Matthew Garrett’s idea: sign the image with the TPM

Matthew Garrett’s patches attack the root of the problem rather than its symptom. The goal is to replace the unencrypted and unauthenticated handling of the hibernation image with a chain of trust backed by the TPM — the Trusted Platform Module, the security chip present on nearly every recent machine.

The proposed design rests on several building blocks. First, the introduction of audited TPM sessions in the kernel — sessions whose use is traceable, so an open session cannot be repurposed. Second, the generation of a TPM signing key dedicated to those audit sessions. Finally, the centrepiece: the hibernation image is signed to guarantee it was not altered during the suspend process.

The principle mirrors the one that protects verified boot: instead of trusting a file sitting on disk, you trust a cryptographic signature that only the TPM can produce. If the image was modified, the signature no longer matches, and the kernel refuses the resume.

Why this is a change, not just a patch

The appeal goes beyond laptop convenience. Hibernation — suspend-to-disk, or S4 in ACPI terminology — is the only sleep state that fully cuts power to RAM. Plain suspend (suspend-to-RAM, S3) keeps a trickle of power and consumes energy continuously; hibernation lets you resume the exact state of the machine after days or weeks, dead battery included.

It is also a building block for trust in disk encryption. On an encrypted machine, hibernation raises a delicate question: where to write the memory image, and how to read it back before the user has even entered their passphrase. A TPM-signed image opens a path where the image is both encrypted and authenticated — which matters directly to enterprise deployments that enable Secure Boot by security policy.

The practical stake is easiest to see on an encrypted laptop. With LUKS full-disk encryption, the kernel cannot simply write the memory image to the swap partition and read it back before the user has unlocked the disk — there is no plaintext path, and the resume happens before the passphrase prompt. The current result is that most encrypted Linux laptops either disable hibernation or fall back to suspend-to-RAM, draining the battery. A TPM-sealed and signed image would let the kernel resume from an authenticated, encrypted blob without exposing it — closing a gap that has quietly annoyed Linux laptop users for years, and that enterprises have long worked around with custom initramfs hooks.

The status remains that of an RFC, though. The patches are proposed for discussion, not yet merged into a stable branch. The road to a production kernel is long: maintainer review, incremental integration, and regression testing across the ACPI stack and storage drivers.

What the TPM adds that encryption alone cannot guarantee

One could object that simply encrypting the hibernation image would solve the problem. Encryption answers confidentiality — it stops the memory being read — but not integrity: an encrypted image can still be modified, and the kernel will decrypt it on resume without knowing it was altered.

This is where the TPM changes the picture. The Trusted Platform Module does not just store keys: it measures the platform’s state at boot, extending a set of registers called PCRs (Platform Configuration Registers) at each stage. That chain of measurements lets a signature be anchored in the machine’s real state, not in an exportable secret.

Matthew Garrett’s patches fit this logic. An audited TPM session gives the kernel a channel of operations whose use is logged and verifiable; a dedicated signing key limits what that session can do. The hibernation image is then signed by a key anchored to the TPM, so that any modification — even by an attacker with physical access to the disk — invalidates the signature.

The precedent is not trivial. Lockdown mode itself was born of the same concern: stopping a kernel verified at boot from being compromised later by overly permissive interfaces. That it is Matthew Garrett, one of lockdown’s historical architects, who now proposes to relax one of its restrictions shows the tool has matured: TPM cryptography is now solid enough to guarantee what lockdown could only block.

What to take away

For now, nothing changes in the behaviour of a production system. The guidance stays the same: if lockdown mode is active, hibernation is unavailable, and no workaround is safe.

  • Do not disable lockdown to get hibernation back. Rolling back reopens every restricted interface, not just suspend-to-disk.
  • Watch the RFC thread. Matthew Garrett’s work is a good signal of where the kernel is heading on TPM-backed trust.
  • Separate sleep and hibernation in your policies. If your laptops need long resumes, plan for S3 as the fallback now, accepting its residual power draw.

The story illustrates a broader trend: kernel security advances by replacing implicit trust with verifiable cryptography. Lockdown closed doors; the TPM-based patches propose to reopen one of them — but with a lock.

Verdict

If you deploy Linux machines with Secure Boot and need hibernation, do not disable lockdown — follow Matthew Garrett’s RFC and plan for S3 until it merges. If you build enterprise images or appliances, anticipate: TPM signing of the hibernation image is the direction the kernel is taking, and it will likely land in upcoming major releases. The immediate lesson stays simple — the security that protects the kernel is not negotiable against a feature, however convenient.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Linux 7.4 makes workqueue flushes 10 to 100 times faster on big servers

On October 22, 2026, a Tejun Heo optimization merged into Linux 7.4 lifts an idle workqueue flush from 40,000 to 4.2 million operations per second on a 192-CPU machine. If you run high-core-count servers, this release hands you a measurable latency win with zero configuration.

Fedora 45 misses its second Go/No-Go and slips to November 3

On October 22, 2026, Fedora’s Go/No-Go meeting declared a second NO-GO: the distribution will not ship next week, held back by blockers touching the eMudhra mitigation, LVM on LUKS, and KDE Discover. Target November 3 as the new date, and read the blocker list as a lesson in release discipline.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss