Hi Ilias,
On Wed, 22 Jan 2025 at 23:23, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Sat, 18 Jan 2025 at 06:31, Simon Glass sjg@chromium.org wrote:
Hi Raymond,
On Wed, 15 Jan 2025 at 13:02, Raymond Mao raymond.mao@linaro.org wrote:
TPM2_PCR_Allocate command is required to re-configurate a TPM device to enable or disable algorithms in run-time, thus this patch introduces the implementation of PCR allocate APIs and adds related cmd functions for testing.
To test the feature, ensure that TPM is started up. Run pcr_allocate command to turn on/off an algorithm, multiple calls are supported and all changes will be cached: `tpm2 pcr_allocate <algorithm_name> <on|off>` Run startup command with argument 'off' to shutdown the TPM. `tpm2 startup TPM2_SU_CLEAR off` Reboot the board via `reset` to activate the changes.
It would be better to have an automated test.
You could create one using the sandbox TPM, and you could add a pytest which can run on my lab (coral has a TPMv2).
The sandbox does not support PCR allocations and I don't personally see the point writing device emulation code.
The point is that we can actually test this code by putting the emulated TPM into a known state before each step and make it easy to debug what is going wrong. The only way to do that on a board is with a cold restart (so the TPM is reset), if that is supported in the lab. I think the QEMU tests are useful; they are somewhere in the middle of the two extremes.
The TPM subsystem definitely needs better testing and I've already discussed this with Raymond.
Well, the TPM tests don't actually work at present, or at least the board I tried.
He will start sending tests later on. We can test simple features on the sandbox, but whatever complex features we need to test will take place in QEMU
Instead, you should spend a little time upgrading the TPM emulation for the tests you need. It will pay dividends in future.
Regards, Simon