Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753999AbdCTJyv (ORCPT <rfc822;w@1wt.eu>);
        Mon, 20 Mar 2017 05:54:51 -0400
Received: from smtp2.infineon.com ([217.10.52.18]:65222 "EHLO
        smtp2.infineon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753331AbdCTJyq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 20 Mar 2017 05:54:46 -0400
X-SBRS: None
From: <Alexander.Steffen@infineon.com>
To: <Peter.Huewe@infineon.com>, <jgunthorpe@obsidianresearch.com>
CC: <James.Bottomley@HansenPartnership.com>,
        <linux-kernel@vger.kernel.org>, <dhowells@redhat.com>,
        <linux-security-module@vger.kernel.org>,
        <tpmdd-devel@lists.sourceforge.net>
Subject: RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands
Thread-Topic: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands
Thread-Index: AQHSlDGsVuxv6NFxVkSful+/J4XXc6GZPWHg///9EQCAAAV6AIAEQkAA
Date: Mon, 20 Mar 2017 09:54:41 +0000
Message-ID: <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com>
References: <20170303151912.14752-1-jarkko.sakkinen@linux.intel.com>
        <20170303151912.14752-3-jarkko.sakkinen@linux.intel.com>
        <22e8fa0caf8b4386a12cd93ee7170ed5@MUCSE603.infineon.com>
 <20170317161614.GA28082@obsidianresearch.com>
 <bca2bee3c1b84100ac72238425ac4791@MUCSE612.infineon.com>
In-Reply-To: <bca2bee3c1b84100ac72238425ac4791@MUCSE612.infineon.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.23.8.247]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v2K9t2ux004542
Content-Length: 1499
Lines: 23

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