[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5C86BF5C-76AA-47DB-B15B-DE524823CF9F@gmx.de>
Date: Wed, 13 Sep 2017 12:01:20 -0700
From: Peter Huewe <peterhuewe@....de>
To: tpmdd-devel@...ts.sourceforge.net,
Ken Goldman <kgold@...ux.vnet.ibm.com>
CC: linux-ima-devel@...ts.sourceforge.net,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance.
Am 13. September 2017 11:52:12 GMT-07:00 schrieb Ken Goldman <kgold@...ux.vnet.ibm.com>:
>On 9/6/2017 12:12 PM, Jason Gunthorpe wrote:
>>
>> The problem with this approach is that the TPM could totally block
>> the CPU for very long periods of time.
>>
>> It seems very risky to enable..
>>
>
>How would you characterize "very long"?
>
>The TPM vendors confirm that they empty the FIFO at internal speeds
>that
>are comparable to the bus speed. Thus, any stall will be sub-usec. Is
>that an issue?
If the tpm does behave correctly, this is fine.
If the tpm hangs for whatever reason, your machine is frozen and you will never figure out why.
That's my concern there.
However ddwg seems fine.
>
>In addition, new TPMs have ever larger FIFO's, making stalls less
>likely
>going forward.
But also reduced the polling loops that introduce the performance penalty ;)
>
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>tpmdd-devel mailing list
>tpmdd-devel@...ts.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
--
Sent from my mobile
Powered by blists - more mailing lists