Thread (24 messages) 24 messages, 6 authors, 2017-08-16

[tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

From: Jarkko Sakkinen <hidden>
Date: 2017-08-11 11:14:27
Also in: lkml

On Wed, Aug 09, 2017 at 11:00:36PM +0200, Peter Huewe wrote:
Hi Ken,
(again speaking only on my behalf, not my employer)
quoted
Does anyone know of platforms where this occurs?
I suspect (but not sure) that the days of SuperIO connecting floppy
drives, printer ports, and PS/2 mouse ports on the LPC bus are over, and
such legacy systems will not have a TPM. Would SuperIO even support the
special TPM LPC bus cycles?
Since we are the linux kernel, we do have to care for legacy devices.
And a system with LPC, PS2Mouse on SuperIO and a TPM are not that uncommon.

And heck, we even have support for 1.1b TPM devices....

quoted
quoted
One more viewpoint: TCG must added the burst count for a reason (might
be very well related what Peter said). Is ignoring it something that TCG
recommends? Not following standard exactly in the driver code sometimes
makes sense on *small details* but I would not say that this a small
detail...
quoted
I checked with the TCG's device driver work group (DDWG). Both the spec
editor and 3 TPM vendors - Infineon, Nuvoton, and ST Micro - agreed that
ignoring burst count may incur wait states but nothing more. Operations
will still be successful.
Interesting - let me check with Georg tomorrow.
Unfortunately I do not have access to my tcg mails from home (since I'm not working :), 
but did you _explicitly_ talk about LPC and the system?
I'm sure the TPM does not care about the waitstates...

If my memory does not betray me, 
it is actually possible to "freeze up" a system completly by flooding the lpc bus.
Let me double check tomorrow...


In anycase - I really would like to see a much more performant tpm subsystem - 
however it will be quite an effort with a lot of legacy testing.
(which I unfortunately cannot spend on my private time ... and also of course lacking test systems).

Thanks,
Peter
I would like to see tpm_msleep() wrapper to replace current msleep()
usage across the subsystem before considering this. I.e. wrapper that
internally uses usleep_range(). This way we can mechanically convert
everything to a more low latency option.

This should have been done already for patch that Mini and Nayna
provided instead of open coding stuff.

That change is something that can be applied right now. On the other
hand, this is a very controversial change.

/Jarkko
--
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help