[U-Boot] [PATCH v4 00/32] Introduce TPMv2.0 support

[Tom Rini <trini@konsulko.com>]

On Tue, May 15, 2018 at 11:56:56AM +0200, Miquel Raynal wrote:

> 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 the support for TPMv2.x chips.
> 
> First, some cleaning is done in TPM-related code. Then, the code is
> split in two categories: generic code (common for both specifications)
> and specific code (only used by one specification).
> 
> Then, basic functionalities are introduced one by one for the v2.x
> specification. TPMv1 vs TPMv2 commands/support distinction is done with
> Kconfig options. Drivers of only one specification can be selected at a
> time.
> 
> A new SPI driver following the TPM v2.x specification is introduced. It
> has been tested on a ST TPM but should be usable with others v2.0
> compliant chips.
> 
> Finally a full Python test suite is added, as well as a Sandbox driver.
> Regular testing may be done through the test/py/ framework when using
> real hardware as well as the Sandbox driver. The following test has run
> more than 300 times without failing with my setup:
> 
>         test/py/test.py --bd <board> -k tpm2
> 
> Available commands for v2.0 TPMs are:
> * STARTUP
> * SELF TEST
> * CLEAR
> * PCR EXTEND
> * PCR READ
> * GET CAPABILITY
> * DICTIONARY ATTACK LOCK RESET
> * DICTIONARY ATTACK CHANGE PARAMETERS
> * HIERARCHY CHANGE AUTH
> 
> Two commands have been written but could not be tested (unsupported by
> the TPM chosen):
> * PCR CHANGE AUTH POLICY
> * PCR CHANGE AUTH VALUE
> 
> With this set of function, minimal TPMv2.0 handling is possible with the
> following sequence.
> 
> * First, initialize the TPM stack in U-Boot.
> 
> > tpm init
> 
> * Then send the STARTUP command to the TPM. The flag is slightly
>   different between the revisions.
> 
> > tpm startup TPM2_SU_CLEAR
> 
> * To enable full TPM capabilities, continue the tests (or do them all
>   again). It seems like self_test_full always waits for the operation to
>   finish, while continue_self_test returns a busy state if called to
>   early.
> 
> > tpm self_test full
> > tpm self_test continue
> 
> * Manage passwords (force_clear also resets a lot of internal stuff).
>   Olderly, TAKE OWNERSHIP == CLEAR + CHANGE AUTH. LOCKOUT is an example,
>   ENDORSEMENT and PLATFORM hierarchies are available too:
> 
> > tpm clear TPM2_RH_LOCKOUT [<pw>]
> > tpm change_auth TPM2_RH_LOCKOUT <new_pw> [<old_pw>]
> 
> * Dictionary Attack Mitigation (DAM) parameters can be changed. It is
>   possible to reset the failure counter and disable the lockout (values
>   erased after a CLEAR). It is then possible to check the parameters
>   have been correctly applied.
> 
> > tpm dam_reset [<pw>]
> > tpm dam_parameters 0xffff 1 0 [<pw>]
> > tpm get_capability 0x0006 0x020e 0x4000000 4
> 
> * PCR policy may be changed (untested).
>   PCR can be extended (no protection against packet replay yet).
>   PCR can be read (the counter with the number of "extensions" is also
>   given).
> 
> > tpm pcr_setauthpolicy 0 12345678901234567890123456789012 [<pw>]
> > tpm pcr_read 0 0x4000000
> > tpm pcr_extend 0 0x4000000
> 
> Thanks,
> Miquèl
> 
> Changes since v3:
> =================
> * Added Simon Glass's RB tags.
> * Moved all the small fixes about lines, alignments, spellings, etc out
>   of the big commit splitting the TPM code structure. Multiple commits
>   have been made for these changes. Now the split is still done in one
>   commit, but it is supposed to be only code moves and headers changes.
> * Used map_sysmem() calls to let Sandbox run TPM commands instead of my
>   hack (allocating memory on the go).
> * Updated the documentation to use the new way of declaring parameters:
>   s/@param x: y/@x: y/.
> * Added two parameters in the chip private structure to store the number
>   of PCRs and the minimum number of bytes needed to address one in a TPM
>   command. This should fit all the TIS TPM2 compliant modules.
> * The above change removes some (wrongly) hardcoded values.
> * Changed the error path as suggested in tpm2_get_capability().
> * Minor rephrasing.
> * Explained in tpm2_get_capability() the offset '19'.
> * Removed useless reset of rx_buf[0] in tpm_tis_spi_xfer().
> * Changed the way spi_xfer return code is checked: error out on any
>   value != 0 instead of just negative ones.
> * Removed unused functions flagged __maybe_unused as well as well as the
>   __maybe_unused flags themselves when not needed.
> * Simplified the validity check of the GPIO as suggested.
> * Updated the compatible property for the SPI modules (as well as the
>   bindings docuementation) to be simply "tis,tpm2-spi" which should work
>   with most compliant chips. Data is linked to this generic compatible
>   in the TPM driver, other values may be added if needed in the future
>   to fit other chips that would use different values than the current
>   ones (used by Infineon SLB 9670 and ST ST33TPHF20 modules, for
>   instance).

Some of the new files have old-style SPDX tags.  If there's no further
changes requested, I'll fix these up when applying.  Thanks again!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180515/294c0a54/attachment.sig>