From mboxrd@z Thu Jan 1 00:00:00 1970 From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe) Date: Mon, 20 Mar 2017 11:23:05 -0600 Subject: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands In-Reply-To: <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> <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com> Message-ID: <20170320172305.GA4990@obsidianresearch.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, Mar 20, 2017 at 09:54:41AM +0000, Alexander.Steffen at 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH v3 2/7] tpm: validate TPM 2.0 commands Date: Mon, 20 Mar 2017 11:23:05 -0600 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> <12e63cdba1e34cac9b82e4bff9621ae6@MUCSE603.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <12e63cdba1e34cac9b82e4bff9621ae6-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net On Mon, Mar 20, 2017 at 09:54:41AM +0000, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org 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. 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755423AbdCTRYR (ORCPT ); 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 ); Mon, 20 Mar 2017 13:24:12 -0400 Date: Mon, 20 Mar 2017 11:23:05 -0600 From: Jason Gunthorpe 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> <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: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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