RE: [PATCH] tpm: do handle area size validation only when TPM space used

Yes, this fixes the issue for me. Thanks. Alexander > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, March 28, 2017 12:25 PM > To: Steffen Alexander (IFAG CCS ESS D SW A) > Cc: tpmdd-de...@lists.sourceforge.net; linux-security- >

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

> Check for every TPM 2.0 command that the command code is supported and > the command buffer has at least the length that can contain the header > and the handle area. This breaks several use cases for me: 1. I've got a TPM that implements vendor-specific command codes. Those cannot be send to

RE: [tpmdd-devel] [PATCH v3 4/7] tpm: infrastructure for TPM spaces

> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm- > interface.c > index 20b1fe3..db5ffe9 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -376,11 +376,12 @@ static bool tpm_validate_command(struct > tpm_chip *chip, const u8 *cmd, >

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

> I think the most straight-forward way to sort this out would be to limit > validation to the resource manager. Sounds good to me. > If I send a fix, would you care to test it? Sure, will do. Alexander

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

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

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

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> > Replace the specification of data structures by pointer dereferences > > as the parameter for the operator "sizeof" to make the corresponding > > size > > determination a bit safer according to the Linux coding style > > convention. > > > This patch does one style in favor of the other. I

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com > wrote: > > > > Replace the specification of data structures by pointer dereferences > > > > as the parameter for the operator "sizeof" to make the corresponding > > > > size > > > > determination a bit safer according to the

RE: [PATCH v2] tpm-dev-common: Reject too short writes

> On Wed, Sep 06, 2017 at 02:19:28PM +, > alexander.stef...@infineon.com wrote: > > > On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote: > > > > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote: > > > > > tpm_transmit() does not offer an explicit interface to

RE: [PATCH v3] tpm-dev-common: Reject too short writes

> On Sat, Sep 09, 2017 at 12:37:39AM +0300, Jarkko Sakkinen wrote: > > On Fri, Sep 08, 2017 at 05:21:32PM +0200, Alexander Steffen wrote: > > > tpm_transmit() does not offer an explicit interface to indicate the > number > > > of valid bytes in the communication buffer. Instead, it relies on the >

RE: [tpmdd-devel] [PATCH v2 0/4] additional TPM performance improvements

> After further discussions with the Device Driver working group (ddwg), > the following changes were made: > > * Check for burstcount at least once to confirm the TPM is ready to accept > the data. Similarly, query for the TPM Expect status as sanity check at > the end. > > * Make the sleep for

RE: [PATCH v2] tpm-dev-common: Reject too short writes

> On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote: > > > tpm_transmit() does not offer an explicit interface to indicate the > > > number of valid bytes in the communication buffer. Instead, it > > > relies on

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > The printk removals do change the objects. > > > > > > The value of that type of change is only for resource limited systems. > > > > I imagine that such small code adjustments are also useful for other > systems. > > Your

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 2017-10-18 at 10:44 +, alexander.stef...@infineon.com wrote: > > > For instance, nothing about > > > > > sizeof(type) > > > > > vs > > > > > sizeof(*ptr) > > > > > makes it easier for a human to read the code. > > > > > > > > If it does not make it easier to read the code

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote: > > > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > > > The printk removals do change the objects. > > > > > > > > > > The value of that type of change is only for resource limited systems. > > > > > > > > I

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote: > > > > > > On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > > > > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com > > > > wrote: > > > > > > > Replace the specification of data

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Fri, Oct 20, 2017 at 12:01:39PM +0300, Jarkko Sakkinen wrote: > > On Thu, Oct 19, 2017 at 04:58:23PM +, > alexander.stef...@infineon.com wrote: > > > > On Tue, Oct 17, 2017 at 11:50:05AM +, > alexander.stef...@infineon.com > > > > wrote: > > > > > > > Replace the specification of data

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > > > >> The TPM burstcount status indicates the number of bytes that can > > > >> be sent to the TPM without causing bus wait states. Effectively, > > > >> it is the number of empty bytes in the command FIFO. > > > >> > > > >>

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> On Wed, Nov 22, 2017 at 06:52:03AM +, > alexander.stef...@infineon.com wrote: > > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when > > > > > > trying > to > > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent > tests > > > > > seem to take an

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> [Mario from Dell added to CC list.] > > Dear Alexander, > > > On 12/11/17 17:08, alexander.stef...@infineon.com wrote: > > >> On 12/08/17 17:18, Jason Gunthorpe wrote: > >>> On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > >>> > I have no access to the system right now,

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> > -Original Message- > > From: alexander.stef...@infineon.com > [mailto:alexander.stef...@infineon.com] > > Sent: Thursday, December 14, 2017 6:21 AM > > To: pmen...@molgen.mpg.de; j...@ziepe.ca > > Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org; > Limonciello, > >

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> [Adding Rafael and Len as they, to my knowledge, also use or have a > access to a Dell XPS 13 9360. With latest Linux master do you get TPM > self-test errors, when cold starting the system without the power supply > plugged in?] > > Dear Mario, dear Alexander, > > > the added line breaks to

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > > >> The TPM burstcount status indicates the number of bytes that can > > >> be sent to the TPM without causing bus wait states. Effectively, > > >> it is the number of empty bytes in the command FIFO. > > >> > > >> This patch

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > >> The TPM burstcount status indicates the number of bytes that can > >> be sent to the TPM without causing bus wait states. Effectively, > >> it is the number of empty bytes in the command FIFO. > >> > >> This patch optimizes the

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> On Thu, Dec 07, 2017 at 03:56:07PM +, alexander.stef...@infineon.com > wrote: > > > > If these are intentional, it’d be great > > > to give some hint to the user, what effect this has. > > > > I agree that those error messages in their current form are not that > > helpful for the users.

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Dear Linux folks, > > > With Linux 4.15-rc2 built by the Ubuntu Kernel Team, the error messages > below are shown by the Linux kernel. These are new. > > ``` > Dez 06 13:22:24 Ixpees kernel: microcode: microcode updated early to > revision 0x62, date = 2017-04-27 > Dez 06 13:22:24 Ixpees

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Dear Jason, > > > On 12/08/17 17:18, Jason Gunthorpe wrote: > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > > > >> I have no access to the system right now, but want to point out, that the > >> log was created by `journactl -k`, so I do not know if that messes with the > >>

RE: [PATCH 0/4] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled

> Hi Hans, > > Thanks a lot for your feedback. > > On 12/20/2017 12:43 PM, Hans de Goede wrote: > > Hi, > > > > On 20-12-17 12:35, Javier Martinez Canillas wrote: > >> Hello, > >> > >> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell > systems") > >> added logic in the TPM TIS

RE: TPM driver breaks S3 suspend

> Hi, > We have a desktop which has S3 suspend (to RAM) problem due to > error messages as follows. > [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns > 38 > [ 198.908293] dpm_run_callback():

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com > wrote: > > > > Replace the specification of data structures by pointer dereferences > > > > as the parameter for the operator "sizeof" to make the corresponding > > > > size > > > > determination a bit safer according to

RE: [PATCH v4 1/4] tpm: move wait_for_tpm_stat() to respective driver files

> On Tue, Oct 17, 2017 at 04:32:29PM -0400, Nayna Jain wrote: > > The function wait_for_tpm_stat() is currently defined in > > tpm-interface file. It is a hardware specific function used > > only by tpm_tis and xen-tpmfront, so it is removed from > > tpm-interface.c and defined in respective

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> The TPM burstcount status indicates the number of bytes that can > be sent to the TPM without causing bus wait states. Effectively, > it is the number of empty bytes in the command FIFO. > > This patch optimizes the tpm_tis_send_data() function by checking > the burstcount only once. And if

RE: Fixing CVE-2017-15361

> On Thu, Oct 26, 2017 at 12:26:10AM +0200, Peter Huewe wrote: > > > > > > Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen > : > > >On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > >> On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen >

RE: Fixing CVE-2017-15361

> On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > wrote: > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists > > > vulnerable FW versions. I think this is the only

RE: Fixing CVE-2017-15361

> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > > wrote: > > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists > > > > vulnerable FW versions. I think this is the

RE: TPM driver breaks S3 suspend

> On Thu, Dec 21, 2017 at 6:19 PM, wrote: > >> Hi, > >> We have a desktop which has S3 suspend (to RAM) problem due to > >> error messages as follows. > >> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > >> [ 198.908289]

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Hi Paul, > > On Mon, 2017-12-11 at 13:54 +0100, Paul Menzel wrote: > > Dear Jason, > > > > > > On 12/08/17 17:18, Jason Gunthorpe wrote: > > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > > > > > >> I have no access to the system right now, but want to point out, that the > >

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> > Replace the specification of data structures by pointer dereferences > > as the parameter for the operator "sizeof" to make the corresponding > > size > > determination a bit safer according to the Linux coding style > > convention. > > > This patch does one style in favor of the other. I

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com > wrote: > > > > Replace the specification of data structures by pointer dereferences > > > > as the parameter for the operator "sizeof" to make the corresponding > > > > size > > > > determination a bit safer according to the

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote: > > > > > > On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > > > > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com > > > > wrote: > > > > > > > Replace the specification of data

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > The printk removals do change the objects. > > > > > > The value of that type of change is only for resource limited systems. > > > > I imagine that such small code adjustments are also useful for other > systems. > > Your

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote: > > > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > > > The printk removals do change the objects. > > > > > > > > > > The value of that type of change is only for resource limited systems. > > > > > > > > I

RE: char-TPM: Adjustments for ten function implementations

> On Wed, 2017-10-18 at 10:44 +, alexander.stef...@infineon.com wrote: > > > For instance, nothing about > > > > > sizeof(type) > > > > > vs > > > > > sizeof(*ptr) > > > > > makes it easier for a human to read the code. > > > > > > > > If it does not make it easier to read the code

RE: [PATCH 0/4] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled

> Hi Hans, > > Thanks a lot for your feedback. > > On 12/20/2017 12:43 PM, Hans de Goede wrote: > > Hi, > > > > On 20-12-17 12:35, Javier Martinez Canillas wrote: > >> Hello, > >> > >> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell > systems") > >> added logic in the TPM TIS

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> [Mario from Dell added to CC list.] > > Dear Alexander, > > > On 12/11/17 17:08, alexander.stef...@infineon.com wrote: > > >> On 12/08/17 17:18, Jason Gunthorpe wrote: > >>> On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > >>> > I have no access to the system right now,

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> > -Original Message- > > From: alexander.stef...@infineon.com > [mailto:alexander.stef...@infineon.com] > > Sent: Thursday, December 14, 2017 6:21 AM > > To: pmen...@molgen.mpg.de; j...@ziepe.ca > > Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org; > Limonciello, > >

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> [Adding Rafael and Len as they, to my knowledge, also use or have a > access to a Dell XPS 13 9360. With latest Linux master do you get TPM > self-test errors, when cold starting the system without the power supply > plugged in?] > > Dear Mario, dear Alexander, > > > the added line breaks to

RE: TPM driver breaks S3 suspend

> Hi, > We have a desktop which has S3 suspend (to RAM) problem due to > error messages as follows. > [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns > 38 > [ 198.908293] dpm_run_callback():

RE: TPM driver breaks S3 suspend

> On Thu, Dec 21, 2017 at 6:19 PM, wrote: > >> Hi, > >> We have a desktop which has S3 suspend (to RAM) problem due to > >> error messages as follows. > >> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > >> [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 >

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Hi Paul, > > On Mon, 2017-12-11 at 13:54 +0100, Paul Menzel wrote: > > Dear Jason, > > > > > > On 12/08/17 17:18, Jason Gunthorpe wrote: > > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > > > > > >> I have no access to the system right now, but want to point out, that the > >

RE: Fixing CVE-2017-15361

> On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > wrote: > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists > > > vulnerable FW versions. I think this is the only responsible action from > > > my side

RE: Fixing CVE-2017-15361

> On Thu, Oct 26, 2017 at 12:26:10AM +0200, Peter Huewe wrote: > > > > > > Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen > : > > >On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > >> On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > >> wrote: > > >> > I'm

RE: Fixing CVE-2017-15361

> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > > wrote: > > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists > > > > vulnerable FW versions. I think this is the only responsible action from > > >

RE: [PATCH v2] tpm-dev-common: Reject too short writes

> On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote: > > > tpm_transmit() does not offer an explicit interface to indicate the > > > number of valid bytes in the communication buffer. Instead, it > > > relies on

RE: [PATCH v2] tpm-dev-common: Reject too short writes

> On Wed, Sep 06, 2017 at 02:19:28PM +, > alexander.stef...@infineon.com wrote: > > > On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote: > > > > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote: > > > > > tpm_transmit() does not offer an explicit interface to

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > > > >> The TPM burstcount status indicates the number of bytes that can > > > >> be sent to the TPM without causing bus wait states. Effectively, > > > >> it is the number of empty bytes in the command FIFO. > > > >> > > > >>

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Dear Linux folks, > > > With Linux 4.15-rc2 built by the Ubuntu Kernel Team, the error messages > below are shown by the Linux kernel. These are new. > > ``` > Dez 06 13:22:24 Ixpees kernel: microcode: microcode updated early to > revision 0x62, date = 2017-04-27 > Dez 06 13:22:24 Ixpees

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> On Thu, Dec 07, 2017 at 03:56:07PM +, alexander.stef...@infineon.com > wrote: > > > > If these are intentional, it’d be great > > > to give some hint to the user, what effect this has. > > > > I agree that those error messages in their current form are not that > > helpful for the users.

RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`

> Dear Jason, > > > On 12/08/17 17:18, Jason Gunthorpe wrote: > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: > > > >> I have no access to the system right now, but want to point out, that the > >> log was created by `journactl -k`, so I do not know if that messes with the > >>

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > >> The TPM burstcount status indicates the number of bytes that can > >> be sent to the TPM without causing bus wait states. Effectively, > >> it is the number of empty bytes in the command FIFO. > >> > >> This patch optimizes the

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> On Wed, Nov 22, 2017 at 06:52:03AM +, > alexander.stef...@infineon.com wrote: > > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when > > > > > > trying > to > > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent > tests > > > > > seem to take an

RE: [PATCH v3] tpm-dev-common: Reject too short writes

> On Sat, Sep 09, 2017 at 12:37:39AM +0300, Jarkko Sakkinen wrote: > > On Fri, Sep 08, 2017 at 05:21:32PM +0200, Alexander Steffen wrote: > > > tpm_transmit() does not offer an explicit interface to indicate the > number > > > of valid bytes in the communication buffer. Instead, it relies on the >

RE: [tpmdd-devel] [PATCH v2 0/4] additional TPM performance improvements

> After further discussions with the Device Driver working group (ddwg), > the following changes were made: > > * Check for burstcount at least once to confirm the TPM is ready to accept > the data. Similarly, query for the TPM Expect status as sanity check at > the end. > > * Make the sleep for

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com > wrote: > > > > Replace the specification of data structures by pointer dereferences > > > > as the parameter for the operator "sizeof" to make the corresponding > > > > size > > > > determination a bit safer according to

RE: [PATCH v4 1/4] tpm: move wait_for_tpm_stat() to respective driver files

> On Tue, Oct 17, 2017 at 04:32:29PM -0400, Nayna Jain wrote: > > The function wait_for_tpm_stat() is currently defined in > > tpm-interface file. It is a hardware specific function used > > only by tpm_tis and xen-tpmfront, so it is removed from > > tpm-interface.c and defined in respective

RE: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

> On Fri, Oct 20, 2017 at 12:01:39PM +0300, Jarkko Sakkinen wrote: > > On Thu, Oct 19, 2017 at 04:58:23PM +, > alexander.stef...@infineon.com wrote: > > > > On Tue, Oct 17, 2017 at 11:50:05AM +, > alexander.stef...@infineon.com > > > > wrote: > > > > > > > Replace the specification of data

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> The TPM burstcount status indicates the number of bytes that can > be sent to the TPM without causing bus wait states. Effectively, > it is the number of empty bytes in the command FIFO. > > This patch optimizes the tpm_tis_send_data() function by checking > the burstcount only once. And if

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

> > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote: > > >> The TPM burstcount status indicates the number of bytes that can > > >> be sent to the TPM without causing bus wait states. Effectively, > > >> it is the number of empty bytes in the command FIFO. > > >> > > >> This patch

RE: [PATCH] tpm: do handle area size validation only when TPM space used

Yes, this fixes the issue for me. Thanks. Alexander > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, March 28, 2017 12:25 PM > To: Steffen Alexander (IFAG CCS ESS D SW A) > Cc: tpmdd-de...@lists.sourceforge.net; linux-security- >

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

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

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

> Check for every TPM 2.0 command that the command code is supported and > the command buffer has at least the length that can contain the header > and the handle area. This breaks several use cases for me: 1. I've got a TPM that implements vendor-specific command codes. Those cannot be send to

RE: [tpmdd-devel] [PATCH v3 4/7] tpm: infrastructure for TPM spaces

> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm- > interface.c > index 20b1fe3..db5ffe9 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -376,11 +376,12 @@ static bool tpm_validate_command(struct > tpm_chip *chip, const u8 *cmd, >

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

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

> I think the most straight-forward way to sort this out would be to limit > validation to the resource manager. Sounds good to me. > If I send a fix, would you care to test it? Sure, will do. Alexander