Design doc: tpmd


Expose an API for using the TPM over DBus; pull all TPM-using code out of programs that currently use it (cryptohome and mount-encrypted).


Right now, programs that want to use the TPM a) have to have access to talk to the TPM, and b) have to use the remarkably-arcane TPM API, which (among other flaws) is very difficult to mock out for testing.


Expose the TPM over DBus.

Detailed Design:

The TPM daemon is a single program connected to DBus and the TPM, running as an otherwise-unprivileged user, providing an API for interacting with the TPM. It should require no privileges at all other than memory allocation and read/write, which makes it a good candidate for sandboxing.

The TPM daemon will present itself as a single DBus object at path /org/chromium/tpmd, implementing two interfaces: the main interface and the nvram interface. Some of these methods can take quite a while, so internally they are implemented asynchronously, but the exposed interface is synchronous as usual. You may need to increase your DBus timeout if making these calls synchronously, as some of them might be quite slow (tens of seconds).

Internally, the main thread will handle DBus interaction, with a worker thread to make blocking calls into the TPM library. We‘ll use libbase’s message loop functionality to wire this up.