Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Mon, Mar 20, 2017 at 09:54:41AM +0000, Alexander.Steffen@infineon.com wrote:
> >>> 2. When upgrading the firmware on my TPM, it switches to a
> >>> non-standard communication mode for the upgrade process and does not
> >>> communicate using TPM2.0 commands during this time. Rejecting
> >>> non-TPM2.0 commands means upgrading won't be possible anymore.
> >>
> >> How non standard? Is the basic header even there? Are the lengths and
> >> status code right?
> >>
> >> This might be an argument to add a 'raw' ioctl or something specifically
> >> for this special case.
> >
> > It follows the regular TPM command syntax and looks something like 1.2
> > commands.
> 
> Yep, so most of it already works with the current implementation.
> 
> There are a few special cases that need some thought though. For
> example, it is possible to use an upgrade to switch the TPM family
> from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> the kernel reinitialize the TPM driver, so it uses the correct
> timeouts for communication, activates the correct features (resource
> manager or not?), etc., without needing to reboot the system.

It would be nice to do this via plug/unplug with existing sysfs
machinery.

> Another problem arises when the upgrade process is interrupted,
> e.g. because power is lost. Then the TPM is stuck in its
> non-standard upgrade mode, so the kernel does not recognize it as a
> valid TPM device and does not export /dev/tpm<n>. But without the
> device node the upgrader is unable to restart the upgrade process,
> leaving the TPM forever inaccessible.

I guess you'd have to teach the TPM core about a new chip mode besides
1.2, 2.0 - some kind of 'upgrade' mode.

So the flow would be to send the upgrade command, unplug/replug the
driver to switch to 'upgrade' mode (which could happen if there was a
reboot?) do the upgrade, then unplug/replug to rediscover the 'new'
TPM.

Jason