Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755423AbdCTRYR (ORCPT <rfc822;w@1wt.eu>);
        Mon, 20 Mar 2017 13:24:17 -0400
Received: from quartz.orcorp.ca ([184.70.90.242]:47841 "EHLO quartz.orcorp.ca"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753950AbdCTRYM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 20 Mar 2017 13:24:12 -0400
Date: Mon, 20 Mar 2017 11:23:05 -0600
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Alexander.Steffen@infineon.com
Cc: Peter.Huewe@infineon.com, 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
Message-ID: <20170320172305.GA4990@obsidianresearch.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>
 <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1926
Lines: 43

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