| Age | Commit message (Collapse) | Author |
|---|
|
TPM2_shutdown command is sharing same structure and logics with
TPM2_startup, thus this patch extends the existing startup APIs and
cmd functions to support shutdown instead of created new ones.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Add an implementation of this, moving the common call to tpm_init() up
into the common API implementation.
Add a test.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
As described in [0] if a command requires use of an untested algorithm
or functional module, the TPM performs the test and then completes the
command actions.
Since we don't check for TPM_RC_NEEDS_TEST (which is the return code of
the TPM in that case) and even if we would, it would complicate our TPM
code for no apparent reason, add a wrapper function that performs both
the selftest and the startup sequence of the TPM.
It's worth noting that this is implemented on TPMv2.0. The code for
1.2 would look similar, but I don't have a device available to test.
[0]
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf
ยง12.3 Self-test modes
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
This feature is used for measured boot, so we can add a log entry to the
TCPA with some information about where the digest comes from. It is not
currently supported in the TPM drivers, but add it to the API so that
code which expects it can signal its request.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
The TPM device has a builtin random number generator(RNG)
functionality. Expose the RNG functions of the TPM device to the
driver model so that they can be used by the EFI_RNG_PROTOCOL if the
protocol is installed.
Also change the function arguments and return type of the random
number functions to comply with the driver model api.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
These functions should really be available outside the TPM code, so that
other callers can find out which version the TPM is. Rename them to have
a tpm_ prefix() and add them to the header file.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Implement this API function for TPM2.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Implement this API function for TPM2.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Add support for TPMv2 versions of API functions. So far this is not
complete as the standard is quite large, but it implements everything
currently available for TPMv2 in U-Boot.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
There are two different TPM standards. U-Boot supports both but each has
its own set of functions. We really need a single TPM API that can call
one or the other. This is not always possible as there are some
differences between the two standards, but it is mostly possible.
Add an API to handle this. So far it is not plumbed into the build and
only supports TPMv1.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
