From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Tue, 20 Mar 2018 15:51:22 +0100 Subject: [U-Boot] [PATCH 00/18] Introduce SPI TPM v2.0 support In-Reply-To: <20180320140455.GQ4418@bill-the-cat.ec.rr.com> References: <20180308154021.25255-1-miquel.raynal@bootlin.com> <20180308172030.GA1770@bill-the-cat.ec.rr.com> <20180309085340.32cf1730@xps13> <20180309121840.GG1770@bill-the-cat.ec.rr.com> <20180320143656.4c1ae678@xps13> <20180320140455.GQ4418@bill-the-cat.ec.rr.com> Message-ID: <20180320155122.3d89acbd@xps13> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Tom, On Tue, 20 Mar 2018 10:04:55 -0400, Tom Rini wrote: > On Tue, Mar 20, 2018 at 02:36:56PM +0100, Miquel Raynal wrote: > > Hi Tom, > >=20 > > Sorry for the delay. > >=20 > > On Fri, 9 Mar 2018 07:18:40 -0500, Tom Rini wrote: > > =20 > > > On Fri, Mar 09, 2018 at 08:53:40AM +0100, Miquel Raynal wrote: =20 > > > > Hi Tom, > > > >=20 > > > > On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini wr= ote: > > > > =20 > > > > > On Thu, Mar 08, 2018 at 04:40:03PM +0100, Miquel Raynal wrote: > > > > > =20 > > > > > > Current U-Boot supports TPM v1.2 specification. The new specifi= cation > > > > > > (v2.0) is not backward compatible and renames/introduces several > > > > > > functions. > > > > > >=20 > > > > > > This series introduces a new SPI driver following the TPM v2.0 > > > > > > specification. It has been tested on a ST TPM but should be usa= ble with > > > > > > others v2.0 compliant chips. > > > > > >=20 > > > > > > Then, basic functionalities are introduced one by one for the v= 2.0 > > > > > > specification. The INIT command now can receive a parameter to > > > > > > distinguish further TPMv1/TPMv2 commands. After that, the libra= ry itself > > > > > > will know which one is pertinent and will return a special erro= r if the > > > > > > desired command is not supported for the selected specification= . =20 > > > > >=20 > > > > > 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 t= hen > > > > > setup automated testing? > > > > > =20 > > > >=20 > > > > 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. > > > >=20 > > > > However, even with these commands, we won't be able to test them in= a > > > > sandbox unless with an actual device. > > > >=20 > > > > I probably miss something, can you explain a bit more what you would > > > > like? =20 > > >=20 > > > 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/ co= de > > > that exercises the TPM commands. Does that make sense? > > > =20 > >=20 > > 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. =20 >=20 > Ah, OK. I thought QEMU had a TPM 2.0 implementation now too, but I see > I'm mistaken. >=20 > > I am certain we all would benefit such a contribution, however I'm > > not sure I could handle that anytime soon. > >=20 > > 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? =20 >=20 > We have the usual linux/stringify.h header 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 =3D 0x12345678; u8 buf[x] =3D { MACRO(value), ...} to be {0x12, 0x34, 0x56, 0x78, ...} > 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=C3=A8l --=20 Miquel Raynal, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com