From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751226AbdCQQQk (ORCPT ); Fri, 17 Mar 2017 12:16:40 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:35294 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751010AbdCQQQi (ORCPT ); Fri, 17 Mar 2017 12:16:38 -0400 Date: Fri, 17 Mar 2017 10:16:14 -0600 From: Jason Gunthorpe To: Alexander.Steffen@infineon.com Cc: jarkko.sakkinen@linux.intel.com, tpmdd-devel@lists.sourceforge.net, dhowells@redhat.com, James.Bottomley@HansenPartnership.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Message-ID: <20170317161614.GA28082@obsidianresearch.com> References: <20170303151912.14752-1-jarkko.sakkinen@linux.intel.com> <20170303151912.14752-3-jarkko.sakkinen@linux.intel.com> <22e8fa0caf8b4386a12cd93ee7170ed5@MUCSE603.infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22e8fa0caf8b4386a12cd93ee7170ed5@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 Fri, Mar 17, 2017 at 03:40:15PM +0000, Alexander.Steffen@infineon.com wrote: > 1. I've got a TPM that implements vendor-specific command > codes. Those cannot be send to the TPM anymore, but are rejected > with EINVAL. > > 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. Jason From mboxrd@z Thu Jan 1 00:00:00 1970 From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe) Date: Fri, 17 Mar 2017 10:16:14 -0600 Subject: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands In-Reply-To: <22e8fa0caf8b4386a12cd93ee7170ed5@MUCSE603.infineon.com> References: <20170303151912.14752-1-jarkko.sakkinen@linux.intel.com> <20170303151912.14752-3-jarkko.sakkinen@linux.intel.com> <22e8fa0caf8b4386a12cd93ee7170ed5@MUCSE603.infineon.com> Message-ID: <20170317161614.GA28082@obsidianresearch.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Fri, Mar 17, 2017 at 03:40:15PM +0000, Alexander.Steffen at infineon.com wrote: > 1. I've got a TPM that implements vendor-specific command > codes. Those cannot be send to the TPM anymore, but are rejected > with EINVAL. > > 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. 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