dasharo-security/tpm-support.robot: Refactor TPM version and support …

[SebastianCzapla]

…tests

Currently, TPM Support and TPM Version test are split into different tests groups. Merging of version and support checks into one allows us to skip few extra reboot cycles during testing. Additionally, it provides opportunity to add coverage for TPM 1.2

[miczyg1]

It is not entirely redundant. See: #495 (comment)

The test to verify TPM version in firmware should check if it is TPM 1.2 or 2.0

[SebastianCzapla]

This branch was rebased onto this #487
Here's a log from dasharo-security test suite run with this patch applied.

dasharo-security.tar.gz

[SebastianCzapla]

Updated and rebased as per suggestions.
Using Setup Menu to detect TPM has a tradeoff, it no longer is automated test for laptop testing. Is this an acceptable tradeoff? @miczyg1

Also, when testing this solution, I found an issue with OptiPlex platform Dasharo/dasharo-issues#1091

[miczyg1]

Updated and rebased as per suggestions. Using Setup Menu to detect TPM has a tradeoff, it no longer is automated test for laptop testing. Is this an acceptable tradeoff? @miczyg1

Also, when testing this solution, I found an issue with OptiPlex platform Dasharo/dasharo-issues#1091

I gave you 3 options and it looks like you chose maybe the worst one. Of course this is not a good tradeoff from laptops perspective. But, was this test even being run on laptops if it only supports SSH tests over OS?

Looks like option 1 is the best, but again it would be limited to UEFI payload only.

Option 2 is the best since it uses coreboot log alone to determine the TPM chip. Based on the TPM chip we may derive what TPM version it is. But this requires the most work.

[SebastianCzapla]

Made a change to use TPM chip as a base for validation. I also kept old log based detection, as a fallback mechanism in case chip detection fails (it happens on Optiplex due to log truncation). Should there be a warning that this mechanism was used? At the moment it only logs to console.

Some TPM variables for various platforms are not set, but I tested it on few laptops and it seems to work correctly.

[miczyg1]

Still don't quite agree on the names of the keywords. They both check logs in cbmem, but doesn't explicitly say which log.

[SebastianCzapla]

@miczyg1 Fixed the names as per suggestion. Additionally, I've introduced small change to get-robot-variables.sh; I changed the usage of path to usage of a variable that holds this path, as it was also missing. Retested after all the changes, here's a log

[miczyg1]

@SebastianCzapla it just needs a rebase before it can be merged fast-forward

[SebastianCzapla]

@miczyg1 Done