linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 0/2] tpm: Simple implementation of tpm_tis_i2c
@ 2019-07-18 17:03 Alexander Steffen
  2019-07-18 17:03 ` [RFC PATCH 1/2] tpm: Make implementation of read16/read32/write32 optional Alexander Steffen
  2019-07-18 17:03 ` [RFC PATCH 2/2] tpm: Add tpm_tis_i2c backend for tpm_tis_core Alexander Steffen
  0 siblings, 2 replies; 7+ messages in thread
From: Alexander Steffen @ 2019-07-18 17:03 UTC (permalink / raw)
  To: linux-integrity, jarkko.sakkinen
  Cc: tmaimon77, oshrialkoby85, Eyal.Cohen, Dan.Morav, Alexander Steffen

Following the discussion in https://lkml.org/lkml/2019/7/5/303 I went ahead and created what I had in mind, trying to keep it as simple as possible. It is meant more as a starting point than a final implementation, as I'm not sure yet how to best integrate it with the existing tpm_tis_core (hence RFC):

It would probably be a cleaner interface, if locality and register address were two separate parameters. I did not implement it here, since that would have meant touching all the tpm_tis_core-based drivers. Also, I noticed that the kernel only ever uses locality 0 anyway. So maybe it would be even better to remove the locality parameter completely and just hardcode locality to 0 where necessary?

I also did not introduce any abstraction for register addresses, but simply remap the well-known addresses from the old TIS versions (which are used within tpm_tis_core) to the corresponding new addresses for I2C before accessing them. Again, it might be cleaner to have maybe an enum to address registers within tpm_tis_core and then a lookup table for the actual addresses in the low-level drivers?

IRQ support is deactivated for the moment, though it probably would work (or at least fall back to polling without catastrophic failures). But I'm not sure what exactly happens when the IRQ code path in tpm_tis_core accesses TPM_INT_VECTOR, which does not exist for I2C. Those accesses should just get ignored by the TPM, but actually testing it would have been more effort.

Speaking of tests, I only verified that basic communication with the TPM (i.e. reading/writing registers) works. For more tests, more test devices would be really helpful, which is why asked for that (https://lkml.org/lkml/2019/7/17/110).

Alexander Steffen (2):
  tpm: Make implementation of read16/read32/write32 optional
  tpm: Add tpm_tis_i2c backend for tpm_tis_core

 drivers/char/tpm/Kconfig        |  11 ++
 drivers/char/tpm/Makefile       |   1 +
 drivers/char/tpm/tpm_tis_core.h |  41 +++++-
 drivers/char/tpm/tpm_tis_i2c.c  | 233 ++++++++++++++++++++++++++++++++
 drivers/char/tpm/tpm_tis_spi.c  |  41 ------
 5 files changed, 283 insertions(+), 44 deletions(-)
 create mode 100644 drivers/char/tpm/tpm_tis_i2c.c

-- 
2.17.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-03-17  8:27 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-18 17:03 [RFC PATCH 0/2] tpm: Simple implementation of tpm_tis_i2c Alexander Steffen
2019-07-18 17:03 ` [RFC PATCH 1/2] tpm: Make implementation of read16/read32/write32 optional Alexander Steffen
2019-08-02 20:12   ` Jarkko Sakkinen
2022-03-15 16:14   ` [PATCH v2] " Johannes Holland
2022-03-17  8:26     ` Jarkko Sakkinen
2019-07-18 17:03 ` [RFC PATCH 2/2] tpm: Add tpm_tis_i2c backend for tpm_tis_core Alexander Steffen
2019-08-02 20:20   ` Jarkko Sakkinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).