SecurityPkg: Fix Tcg2SubmitCommand in TPM field upgrade scenario #11750
Conversation
tianocore-assign-reviewers
bot
requested review from
arunsbaskaran and
jyao1
liqiqiii
force-pushed
the
personal/liqiqi/fixtpmupdate
branch
from
b7b98a3 to
ce55036
Compare
|
That is good problem statement. Question: If the TPM failed due to Field Upgrade and cause PCR missing event log entry, do we want to continue boot OS directly without reset? |
Hi Jiewen, this is a good question. I believe when the TPM failed the field upgrade, we won't be able to boot to the OS, as the TPM will stay in field upgrade mode, which has very limited functionalities in that case. The change here just makes sure that when the TPM is in this mode we can still talk to TPM and try to do TPM recovery the next boot. |
liqiqiii
force-pushed
the
personal/liqiqi/fixtpmupdate
branch
4 times, most recently
from
bbf20d8 to
dcb5a60
Compare
There's a bug that after the device was forced shut down during the tpm firmware update process, then the TPM will stay in field upgrade mode and refuse to work properly. This will block TPM startup and cause the device to bootloop. Now in the TCG_DXE_DATA struct we don’t have a flag to indicate the current TPM mode, and we will simply treat the upper Scenario with this DEVICE_ERROR and set the TPMPresentFlag to FALSE. Later in Tcg2SubmitCommand we will just return DEVICE_ERROR and skip the actual TPM recovery. We should have an extra flag that check for the TPM response code and if it's TPM_RC_UPGRADE, we knew the device is in field upgrade mode and should continue the workflow. We should only return EFI_DEVICE_ERROR when both TPMPresentFlag and TpmUpdateFlag are false. The field upgrade is part of TCG spec, and the capsule update/recovery is part of UEFI spec. Make this PR to bring in the fix for this corner case. Signed-off-by: Liqi Qi <[email protected]>
liqiqiii
force-pushed
the
personal/liqiqi/fixtpmupdate
branch
from
dcb5a60 to
9874e0e
Compare
liqiqiii
changed the title
|
@jyao1 @arunsbaskaran I have updated the PR and all tests are passing, could you take a look? |
2 participants
Description
Fix Tcg2SubmitCommand in TPM field upgrade scenario.
There's a bug that after the device was forced shut down during the tpm firmware update process,
then the TPM will stay in field upgrade mode and refuse to work properly. This will block TPM startup and cause the device to bootloop.
Now in the TCG_DXE_DATA struct we don’t have a flag to indicate the current TPM mode, and we will simply treat the upper
Scenario with this DEVICE_ERROR and set the TPMPresentFlag to FALSE.
Later in Tcg2SubmitCommand we will just return DEVICE_ERROR and skip the actual TPM recovery.
We should have an extra flag that check for the TPM response code and if it's TPM_RC_UPGRADE, we knew the device is in field upgrade mode and should continue the workflow.
After I commented out the TpmPresentFlag check, the device will be able to continue with the TPM recovery using the data stashed in persisted blob and finish the TPM capsule update successfully, and I can boot to the OS with TPM working.
We should only return EFI_DEVICE_ERROR when both TPMPresentFlag and TpmUpdateFlag are false.
The field upgrade is part of TCG spec, and the capsule update/recovery is part of UEFI spec.
Make this PR to bring in the fix for this corner case.
How This Was Tested
Tested with a device running dTPM, force shutdown the device during TPM capsule update, and in the reboot it can go into tpm recovery flow and update the TPM firmware correctly. Checked in Device Manager, version has been updated.