bcm63xx/u-boot/drivers/tpm/Kconfig, branch master

tpm: make TPM_V2 be compiled by default

2018-07-28T15:58:09Z

TPM_V1 was already compiled by default. Now that both can be compiled at the same time, compiled them both by default. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass

tpm: allow TPM v1 and v2 to be compiled at the same time

2018-07-28T15:57:38Z

While there is probably no reason to do so in a real life situation, it will allow to compile test both stacks with the same sandbox defconfig. As we cannot define two 'tpm' commands at the same time, the command for TPM v1 is still called 'tpm' and the one for TPM v2 'tpm2'. While this is the exact command name that must be written into eg. test files, any user already using the TPM v2 stack can continue to do so by just writing 'tpm' because as long as TPM v1 support is not compiled, U-Boot prompt will search for the closest command named after 'tpm'. The command set can also be changed at runtime (not supported yet, but ready to be), but as one can compile only either one stack or the other, there is still one spot in the code where conditionals are used: to retrieve the v1 or v2 command set. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass [trini: In sandbox_tpm2_fill_buf() use NULL not \0 to ensure NULL terminated string due to LLVM warning] Signed-off-by: Tom Rini

tpm: remove stale symbol in Kconfig

2018-07-28T15:55:32Z

The TPM_DRIVER_SELECTED symbol was used in one of the initial series about TPMv2 but its use has been dropped, making these selects useless, remove them. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass

tpm: compile Sandbox driver by default

2018-07-28T15:55:32Z

When Sandbox and the TPM stack are both selected, compile Sandbox TPM driver by default. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass

tpm: add a Sandbox TPMv2.x driver

2018-05-26T00:13:00Z

This driver can emulate all the basic functionalities of a TPMv2.x chip and should behave like them during regular testing. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass Reviewed-by: Tom Rini

tpm: add support for TPMv2.x SPI modules

2018-05-26T00:12:59Z

Add the tpm2_tis_spi driver that should support any TPMv2 compliant (SPI) module. Signed-off-by: Miquel Raynal Reviewed-by: Tom Rini Reviewed-by: Simon Glass

tpm: disociate TPMv1.x specific and generic code

2018-05-26T00:12:55Z

There are no changes in this commit but a new organization of the code as follow. * cmd/ directory: > move existing code from cmd/tpm.c in cmd/tpm-common.c > move specific code in cmd/tpm-v1.c > create a specific header file with generic definitions for commands only called cmd/tpm-user-utils.h * lib/ directory: > move existing code from lib/tpm.c in lib/tpm-common.c > move specific code in lib/tpm-v1.c > create a specific header file with generic definitions for the library itself called lib/tpm-utils.h * include/ directory: > move existing code from include/tpm.h in include/tpm-common.h > move specific code in include/tpm-v1.h Code designated as 'common' is compiled if TPM are used. Code designated as 'specific' is compiled only if the right specification has been selected. All files include tpm-common.h. Files in cmd/ include tpm-user-utils.h. Files in lib/ include tpm-utils.h. Depending on the specification, files may include either (not both) tpm-v1.h or tpm-v2.h. Signed-off-by: Miquel Raynal Reviewed-by: Tom Rini [trini: Fix a few more cases of tpm.h -> tpm-v1.h, some Kconfig logic] Signed-off-by: Tom Rini

tpm: prepare introduction of TPMv2.x support in Kconfig

2018-05-26T00:12:33Z

Because both major revisions are not compatible at all, let's make them mutually exclusive in Kconfig. This way we will be sure, when using a command or a library function that it is supported by the right revision. Current drivers are currently prefixed by "tpm_", we will prefix TPMv2.x files by "tpm2_" to make the distinction without moving everything. The Kconfig menu about TPM drivers is now divided into two sections, one for each specification. Compliant drivers with one specification will only show up if this specification _only_ has been selected, otherwise a comment is displayed. Once a driver is selected by the user, it selects automatically a boolean value, that is needed in order to activate the TPM commands. Selecting the TPM commands will automatically select the right command/library files. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass Reviewed-by: Tom Rini [trini: Rework deps as TPM_V1 and TPM_V2 depend on TPM, drop TPM_DRIVER_SELECTED] Signed-off-by: Tom Rini

lib: tpm: Add command to list resources

2017-03-26T19:22:58Z

It is sometimes convenient to know how many and/or which resources are currently loaded into a TPG, e.g. to test is a flush operation succeeded. Hence, we add a command that lists the resources of a given type currently loaded into the TPM. Signed-off-by: Mario Six Reviewed-by: Simon Glass

tpm: Add function to load keys via their parent's SHA1 hash

2017-03-26T19:22:58Z

If we want to load a key into a TPM, we need to know the designated parent key's handle, so that the TPM is able to insert the key at the correct place in the key hierarchy. However, if we want to load a key whose designated parent key we also previously loaded ourselves, we first need to memorize this parent key's handle (since the handles for the key are chosen at random when they are inserted into the TPM). If we are, however, unable to do so, for example if the parent key is loaded into the TPM during production, and its child key during the actual boot, we must find a different mechanism to identify the parent key. To solve this problem, we add a function that allows U-Boot to load a key into the TPM using their designated parent key's SHA1 hash, and the corresponding auth data. Signed-off-by: Mario Six Reviewed-by: Simon Glass