TPM003.004 Test should be documented and implemented in OSFV

[philipanda]

Device

RTE version

OSFV version

develop

Affected component(s) or functionality

TPM003.004 test case

Brief summary

The test case is not documented in docs.dasharo nor implemented in osfv which makes it rather difficult to perform

How reproducible

100%

How to reproduce

The test is commented out and marked as TODO in OSFV. See the dasharo-security/tpm-support.robot test suite. The test is not documented on docs.dasharo. See https://docs.dasharo.com/unified-test-documentation/dasharo-security/200-tpm-support/

Expected behavior

The test should be implemented or at least documented if it should be performed.

Actual behavior

It is not

Link to screenshots or logs

Some tips on the expected behavior can be found on an old, closed issue Dasharo/dasharo-issues#521

Additional context

No response

Solutions you've tried

No response

[pietrushnic]

I'm looking at this test from the perspective of Dasharo (coreboot+SeaBIOS), where there is the possibility of changing banks; my concern is regarding PPI: are we considering redirected serial a valid PPI?

Looking at TPM0003.001, I wonder if we correctly validate that.

P.S. @philipandag, I doubt leaving a bug without an assignee's help in resolving it. @macpijan, shouldn't this repo have a "need review" label? Maybe there is also a bug scrub meeting needed to accelerate resolving issues in OSFV?

[miczyg1]

I'm looking at this test from the perspective of Dasharo (coreboot+SeaBIOS), where there is the possibility of changing banks; my concern is regarding PPI: are we considering redirected serial a valid PPI?

Serial is a physical port generally so you have to be present to interact with it. All operations made in the firmware setup are assumed to be done by physically present user IIRC. Still the mechanism is different between SeaBIOS and EDK2:

1. SeaBIOS will simply change the PCR bank and it already takes effect after reboot.
2. EDK2 will save your request to change PCR banks to RAM and reset. Then if the request is detected after the reset, you have to confirm that you really requested this operation and proceed with changes. Only then a final reset happens which applies the changes to PCR banks.

So SeaBIOS does not use PPI at all. It simply switches the banks immediately.

If the redirected serial is a valid PPI, it depends on a case:

1. Physical serial port on a machine which you interface with locally - I think yes.
2. Physical serial port but connected to a device which gives access to this serial remotely - I think no. But that is your choice to expose it remotely...
3. Virtual serial port such as BMC SOL - I think no.

Looking at TPM0003.001, I wonder if we correctly validate that.

The test verifies firmware support, os it is tricky. You have to somehow ensure that the firmware handles the TPM properly. I didn't liek the approach of using TPM event log in cbmem, because it proves nothing. There are some ramblings from my side about it here: #507 (comment)

[philipanda]

P.S. @philipandag, I doubt leaving a bug without an assignee's help in resolving it.

Never have I been instructed to assign anyone to my issues here, only PRs. Should this be a common practice?

[pietrushnic]

Never have I been instructed to assign anyone to my issues here, only PRs. Should this be a common practice?

I understand, and there is nothing wrong with your side. By default, if you don't get a response, it is worth bringing attention through other means. The question is for @macpijan. I am trying to advertise for a bug scrub meeting. If we don't have different ideas, let's schedule a call every month or every two weeks and start cleaning up things. That could raise awareness in this repo and lower maintenance costs.

[JakubRed]

This test now has updated ID: TPM003.101. Changed in #732

[krystian-hebel]

@macpijan the PR linked above adds a test for UEFI, but not for SeaBIOS that was also mentioned. Is this enough to close this issue?