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

[Alexander.Steffen at infineon.com]

>>> 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.

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'll try to work on those problems in the coming weeks and provide the fixes. Any input is appreciated.

Alexander
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ¥Šwÿº{.nÇ+‰·¥Š{±þÇœº¸­Ëù¨vé^þ)í…æèw*jg¬±¨¶‰šŽŠÝ¢jÿ¾«þG«éÿ¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø¯ù®w¥þŠàþf£¢·hšâúÿ†Ù¥