Use Resource Manager (/dev/tpmrrm0) rather then /dev/tpm0

[bugraaydogar]

Hi,

The snapd reports the following error message when an application snap tries to open up the /dev/tpm0.
stateengine.go:149: state ensure error: devicemgr: cannot connect to TPM: no TPM2 device is available

Any application snap could block the use of /dev/tpm0 and therefore, we might consider using the resource manager (/dev/tpmrmx) rather than using the /dev/tpm0 as described here => https://github.com/snapcore/secboot/blob/master/internal/tcti/tcti.go#L29

In addition to that, potentially, we might want to change the snapd's tpm interface to block access to /dev/tpmx directly. => https://github.com/snapcore/snapd/blob/master/interfaces/builtin/tpm.go#L36

What do you think?

Thanks,
Bugra

[chrisccoulson]

Yes, ultimately we should use the resource manager backed device, although I'd rather not during early boot because it's not really necessary there.

There are some additional challenges / risks here:

• I'm not sure how much real world testing the kernel resource manager has had.
• Using the resource manager introduces the possibility that the TPM state may change during a transaction (composed of multiple commands) that's initiated by snapd. We'll need to make sure that secboot is ready to handle these scenarios.

So whilst we should move towards using it, it's not quite as simple as changing the device path to /dev/tpmrm0.

(On a related note, go-tpm2 has a proper API for iterating / accessing TPM devices now that doesn't rely on specifying the device path - https://pkg.go.dev/github.com/canonical/[email protected]/linux#DefaultTPM2Device. And there's an accessor for the resource manager backed device as well - https://pkg.go.dev/github.com/canonical/[email protected]/linux#TPMDeviceRaw.ResourceManagedDevice)