Garrett: Making hibernation work under Linux Lockdown

[Posted February 22, 2021 by corbet]

Matthew Garrett recently posted a patch set enabling hibernation on systems that are running in the UEFI secure-boot lockdown mode. This blog entry gets into the details of how it all works. "When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel."

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 22, 2021 19:58 UTC (Mon) by IanKelling (subscriber, #89418) [Link] (12 responses)

As far as I know, the TPM firmware is nonfree and upgradable. That firmware could have a backdoor (or there is a good chance it has a security flaw, since nonfree firmware often does).

I like the part how he couldn't get the TPM to work as documented, he didn't mention this, but..., no source code to see why.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 22, 2021 20:22 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (2 responses)

Sure, in the same way that we have to trust that the CPU behaves as documented, that your chipset isn't conspiring with other devices to permit sensitive data to be DMAed out, and so on. I'd love to see TPMs with an open design and free firmware (the OpenTitan project is a potential way of getting there), but until we have an entirely free platform we're implicitly placing trust in components that we can't verify.

The failure with localities has nothing to do with the TPM - the motherboard chipset literally isn't forwarding the accesses to the bus. Source code to the TPM isn't going to help anyone there.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 22, 2021 23:01 UTC (Mon) by IanKelling (subscriber, #89418) [Link]

> The failure with localities has nothing to do with the TPM

Interesting.

I see an article about something that has nonfree upgradable firmware without it being mentioned, I'm compelled to point it out as a consideration. I don't think they are the worst case of nonfree firmware out there at all.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 16:45 UTC (Tue) by hmh (subscriber, #3838) [Link]

Indeed, Intel TXT has this:

Locality 0: Always open for general use.
Locality 1: Operating system (not used as part of TXT).
Locality 2: System software (OS) in secure mode. Only after the OS has successfully performed a secure launch. The OS may close this access at any time.
Locality 3: ACMs. Only an ACM that has been invoked by the GETSEC instruction has access to locality 3.
Locality 4: Hardware. Only the processor executing its microcode has Locality 4 access.

Other vendors and/or platform TPM implementations might have done something to the same effect.

That said, Intel might help the Linux kernel get access to (1) and (2) if you ask the Right People [tm] -- no idea who they are, but there's a chance they might read this.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 10:00 UTC (Tue) by dottedmag (subscriber, #18590) [Link] (3 responses)

Why the emphasis on firmware?

Hardware/firmware boundary is quite fluid and moves around based on economics of manufacturing: more logic in gates means less logic in firmware, and vice versa.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 18:21 UTC (Tue) by floppus (guest, #137245) [Link] (1 responses)

Yes, and the software/firmware boundary, if you will, is fluid as well.

Free firmware is often more useful and more important than free hardware because firmware *is* easier to modify. If you have the source, and a way to load new firmware, a reasonably motivated person can hack their device to do interesting things that the manufacturer didn't intend or anticipate; whereas manufacturing your own TPM, say, is far beyond most people's capabilities. And on the flip side, modifiable firmware is a tempting vector for malware, which hardware (being non-modifiable) isn't.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 23:41 UTC (Tue) by pabs (subscriber, #43278) [Link]

There is also the proprietary firmware in ROM, which often has security vulnerabilities (checkra.in for eg), perhaps some of which could be useful to malware authors when chained together with other vulnerabilities.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 18:29 UTC (Tue) by brunowolff (guest, #71160) [Link]

If you look at something like the NSA's tailored access operations, it is going to be harder to change a CPU for a small number of people than to replace the firmware for a small number of people.

If a system is compromised, you can't generally change the CPU (though you might be able to destroy it), but depnding how access to the firmware is controlled, it might be possible to change it to gain persistent access to that machine.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 19:55 UTC (Tue) by flussence (guest, #85566) [Link] (4 responses)

That depends on the TPM. Desktop motherboards sometimes have a pin header for an external TPM, and there's no reason why there couldn't be open hardware for that like there is for U2F.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 22:05 UTC (Tue) by mss (subscriber, #138799) [Link] (3 responses)

That would need to be a a custom ASIC since if it uses an off-the-shelf secure MCU then it would merely shift trust from the TPM manufacturer to the MCU manufacturer.
And one can argue that even then the chip would need random die inspections to gain confidence that the foundry haven't backdoored it.

Even just utilizing the TPM motherboard header for LPC access and running a totally different protocol than TPM uses doesn't really change much here.

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 23, 2021 23:49 UTC (Tue) by pabs (subscriber, #43278) [Link]

There is a lot more to trustworthy hardware than die inspections, some links along those lines from bunnie that I found interesting:

https://www.bunniestudios.com/blog/?p=5706
https://lwn.net/Articles/808129/
https://lwn.net/Articles/743822/
https://lwn.net/Articles/743602/
https://www.youtube.com/watch?v=zXwy65d_tu8
https://riscv.org/wp-content/uploads/2017/05/Wed1100-impe...

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 24, 2021 9:50 UTC (Wed) by geert (subscriber, #98403) [Link] (1 responses)

Or a Lattice iCE40 or ECP5 FPGA, implementing a RISC-V core?

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 24, 2021 13:50 UTC (Wed) by mss (subscriber, #138799) [Link]

That's only marginally better than off-the-shelf secure MCU in terms of trust.

Besides that, do these cores have any secure storage?

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 27, 2021 22:12 UTC (Sat) by wt (subscriber, #11793) [Link] (1 responses)

Would this also enable hybrid suspend? Like where you suspend and then hibernate after some longer period of time?

Garrett: Making hibernation work under Linux Lockdown

Posted Feb 28, 2021 12:56 UTC (Sun) by pabs (subscriber, #43278) [Link]

Would hibernate and then suspend not be the better option? Hibernation is a pretty resource intensive operation, overheating and shutdown during hibernation while in your bag wouldn't be nice.