Introduce SPI TPM v2.0 support
Get series with b4
b4 am 20180320155122.3d89acbd@xps13Versions newest first
- v1 Latest0 of 18 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 18 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 00/18] Introduce SPI TPM v2.0 support
Hi Tom,
Quoted 61 lines · Tom Rini
Quoted 48 lines · Miquel Raynal
Hi Tom,
Sorry for the delay.
Quoted 33 lines · Tom Rini
Quoted 32 lines · Miquel Raynal
Hi Tom,
Quoted 16 lines · Tom Rini
Quoted 8 lines · Miquel Raynal
Current U-Boot supports TPM v1.2 specification. The new specification (v2.0) is not backward compatible and renames/introduces several functions.
This series introduces a new SPI driver following the TPM v2.0 specification. It has been tested on a ST TPM but should be usable with others v2.0 compliant chips.
Quoted 5 lines
Then, basic functionalities are introduced one by one for the v2.0 specification. The INIT command now can receive a parameter to distinguish further TPMv1/TPMv2 commands. After that, the library itself will know which one is pertinent and will return a special error if the desired command is not supported for the selected specification.
Quoted 4 lines
Thanks for doing all of this. Can you please enable this feature on sandbox and/or an x86 QEMU variant where I assume we could also then setup automated testing?
Not sure I understand your request correctly: the TPM commands are already available in the sandbox (I don't see what I could add), I just extended the current set of commands.
However, even with these commands, we won't be able to test them in a sandbox unless with an actual device.
Quoted 8 lines
Quoted 2 lines
I probably miss something, can you explain a bit more what you would like?
Can we add a valid TPM via QEMU and then test it that way? If so, we should enable the TPM code on qemu-x86_64 (and, well, if we can pass it on other arches, other QEMU targets) and write some test/py/tests/ code that exercises the TPM commands. Does that make sense?
Quoted 5 lines
I suppose this is doable, but for what I know, the effort is consequent. TPM 2.0 are not compatible at all with TPM 1.x , the packets exchanged at TPM level are completely different. Hence, I think there is almost nothing that we can take from the TPM 1.x implementation already existing in QEMU.
Ah, OK. I thought QEMU had a TPM 2.0 implementation now too, but I see I'm mistaken.
Quoted 3 lines
I am certain we all would benefit such a contribution, however I'm not sure I could handle that anytime soon.
Quoted 6 lines
Quoted 3 lines
About the series, I think it would be better that I change a macro name ("STRINGIFY", which is wrongly named), I will send a v2 soon, can you tell me its status otherwise?
We have the usual
linux/stringify.hheader available, so yes, you should make use of that.
Actually the name is misleading as I don't want to "stringify".
I am looking for a way to easily fill a buffer of bytes from integer values, ie:
u32 value = 0x12345678;
u8 buf[x] = { MACRO(value), ...} to be {0x12, 0x34, 0x56, 0x78, ...}
Quoted 4 lines
And I still would like to see tests written, even if
they can only be executed on $board with $TPM attached via $interface, with those 3 variables documented so that others can try it out too. Does that make sense? Thanks!
I see some TPM tests for v1.x, I can probably add some there. This will test the library functions but not the "user" commands.
To test the commands, I suggest following the lines I inserted in my cover letter, but maybe I can put it also in some documentation?
Would this fit your expectations?
[1] https://lists.denx.de/pipermail/u-boot/2018-March/322286.html
Thanks,
Miquèl
Signature · 3 lines
Miquel Raynal, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com