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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com>
Date:   Mon, 20 Mar 2017 09:54:41 +0000
From:   <Alexander.Steffen@...ineon.com>
To:     <Peter.Huewe@...ineon.com>, <jgunthorpe@...idianresearch.com>
CC:     <James.Bottomley@...senPartnership.com>,
        <linux-kernel@...r.kernel.org>, <dhowells@...hat.com>,
        <linux-security-module@...r.kernel.org>,
        <tpmdd-devel@...ts.sourceforge.net>
Subject: RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands

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