Add checking as to whether the current TPM state is valid, so we can
implement reading/writing the state.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix the warning:
drivers/tpm/tpm2_tis_sandbox.c: In function ‘sandbox_tpm2_xfer’:
drivers/tpm/tpm2_tis_sandbox.c:288:48: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 2 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
printf("TPM2: Unmatching length, received: %ld, expected: %d\n",
~~^
%d
send_size, length);
~~~~~~~~~
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
We have an existing U-Boot header for the one function that this defines.
Use that instead of the linux/ one. Move over the nice comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The recv variable in sandbox_tpm2_fill_buf() is a pointer on a pointer
of a char array. It means accessing *recv is the char array pointer
itself while **recv is the first character of that array. There is no
need for such indirection here, so simplify the code.
Simplifying things will make the last assignment right: "*recv = NULL"
is now correct. The issue has been found by the following Coverity
Scan report:
CID 183371: Incorrect expression (UNUSED_VALUE)
Assigning value "4UL" to "*recv" here, but that stored value is overwritten before it can be used.
232 *recv += sizeof(rc);
233
234 /* Add trailing \0 */
235 *recv = NULL;
While at simplifying things, use '\0' instead of NULL when adding an
empty char at the end of the buffer.
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The second check on pcr_map in sandbox_tpm2_xfer() is wrong. It should
check for pcr_map not being empty. Instead, it is a pure copy/paste of
the first check which is redundant.
This has been found thanks to a Coverity Scan report:
CID 183370: Memory - illegal accesses (UNINIT)
Using uninitialized value "pcr_index".
put_unaligned_be32(tpm->pcr_extensions[pcr_index], recv);
This is because pcr_index is initialized only if the user input is
correct, ie. at least one valid bit is set in pcr_map.
Fix the second check and also initialize pcr_index to 0 (which is
harmless in case of error) to make Coverity Scan happy.
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: In sandbox_tpm2_fill_buf() use NULL not \0 to ensure NULL
terminated string due to LLVM warning]
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
