On Thu, Oct 08, 2026 at 06:20:16AM -0700, Matthew Garrett wrote: > Hibernation writes out the full system state to disk in an unencrypted > and unauthenticated manner. Resuming from hibernate reads that data and > throws it directly into RAM, then jumps into it. This is effectively an > entirely unauthenticated mechanism for putting whatever you want into > kernel space. This violates the assumptions around lockdown (root can > write whatever they want to the swap partition and then trigger a > resume), and as such lockdown blocks hibernate. > > This has made many people unhappy. > > This patchset seeks to solve this problem. In order for hibernation to > be trustworthy we need to be able to prove that the image was generated > by the kernel and not modified after that. This is not an easy task, and > requires some infrastructural framework. To that end, this patchset does > the following: > > 1) Co-opts a TPM NV index for the kernel's sole use. This is currently a > placeholder and we should register one explicitly from an appropriate > range in order to ensure that we don't conflict with userland. > > 2) Does something horrifying with PCR 5 in order to prove that a given > kernel supports (1). We need to extend and cap a PCR before userland is > running in order to prove that the kernel has support for this feature, > but since we don't currently cap any PCRs there's nothing stopping > userland from doing the same and so achieving the same state. The way > around this is to rely on a feature of PCR 5 - it is extended as a > result of ExitBootServices being called, and since the boot stub can > execute code before that happens we can perform the proof extension > there and then have it implicitly capped by the firmware's extension. > > 3) Adds support for audited TPM sessions in the kernel, allowing us to > generate signed digests of the commands that were executed in that > session and their results > > 4) Adds support for generating a predictable AK that can be used to sign > digests from those audit sessions > > 5) Adds support for generating a TPM signing key in such a session, and > using the signed digest to prove that the session took place in the > kernel > > 6) Signs the hibernation image with such a key > > An old kernel that doesn't implement (1) won't be able to mimic the same > PCR 5 value. Userland won't be able to mimic the NV index value because > the kernel will block it. This means that the only way that key could > have been created is by the kernel, and so we can trust that the image > was generated by the kernel. > > QUESTIONS: > > 1) I haven't tried to make the key management generic, since this isn't > intended to ever be exposed to userland in any way. Should it be > integrated into the trusted keys layer anyway? > > 2) Filtering TPM commands from userland isn't ideal - anyone able to > poke commands into the TPM directly is in a position to violate the > assumptions here. Is there any way we can get a secret into the kernel > that can be used as an auth value? It would need to be impossible to > obtain from userland and it would need to be consistent over platform > reboots. >
Now I have finally all priority stuff out of the way. I'll start by refining my test harness to always have regular hibernate enabled and fully working. Once I get that out of the way this patch set should become low-effort to test. Br, Jarkko
