Post Syndicated from original https://mjg59.dreamwidth.org/63219.html

I’ve been ridiculously burned out for a while now but I’m taking the month off to recover and that’s giving me an opportunity to catch up on a lot of stuff. This has included me actually writing some code to work with the Pluton in my Thinkpad Z13. I’ve learned some more stuff in the process, but based on everything I know I’d still say that in its current form Pluton isn’t a threat to free software.

So, first up: by default on the Z13, Pluton is disabled. It’s not obviously exposed to the OS at all, which also means there’s no obvious mechanism for Microsoft to push out a firmware update to it via Windows Update. The Windows drivers that bind to Pluton don’t load in this configuration. It’s theoretically possible that there’s some hidden mechanism to re-enable it at runtime, but that code doesn’t seem to be in Windows at the moment. I’m reasonably confident that “Disabled” is pretty genuinely disabled.

Second, when enabled, Pluton exposes two separate devices. The first of these has an MSFT0101 identifier in ACPI, which is the ID used for a TPM 2 device. The Pluton TPM implementation doesn’t work out of the box with existing TPM 2 drivers, though, because it uses a custom start method. TPM 2 devices commonly use something called a “Command Response Buffer” architecture, where a command is written into a buffer, the TPM is told to do a thing, and the response to the command ends up in another buffer. The mechanism to tell the TPM to do a thing varies, and an ACPI table exposed to the OS defines which of those various things should be used for a given TPM. Pluton systems have a mechanism that isn’t defined in the existing version of the spec (1.3 rev 8 at the time of writing), so I had to spend a while staring hard at the Windows drivers to figure out how to implement it. The good news is that I now have a patch that successfully gets the existing Linux TPM driver code work correctly with the Pluton implementation.

The second device has an MSFT0200 identifier, and is entirely not a TPM. The Windows driver appears to be a relatively thin layer that simply takes commands from userland and passes them on to the chip – I haven’t found any userland applications that make use of this, so it’s tough to figure out what functionality is actually available. But what does seem pretty clear from the code I’ve looked at is that it’s a component that only responds when it’s asked – if the OS never sends it any commands, it’s not able to do anything.

One key point from this recently published Microsoft doc is that the whole “Microsoft can update Pluton firmware” thing does just seem to be the ability for the OS to push new code to the chip at runtime. That means Microsoft can’t arbitrarily push new firmware to the chip – the OS needs to be involved. This is unsurprising, but it’s nice to see some stronger confirmation of that.

Anyway. tl;dr – Pluton can (now) be used as a regular TPM. Pluton also exposes some additional functionality which is not yet clear, but there’s no obvious mechanism for it to compromise user privacy or restrict what users can run on a Free operating system. The Pluton firmware update mechanism appears to be OS mediated, so users who control their OS can simply choose not to opt in to that.

comments