On Mon, Mar 20, 2017 at 09:54:41AM +0000, alexander.stef...@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
