Enable the physical presence interface for TPM 1.2. It is required for the TPM 1.2 menu to work. Cc: Jiewen Yao <jiewen.yao@...> Cc: Jian J Wang <jian.j.wang@...> Cc: Ard Biesheuvel <ardb+

From: Gerd Hoffmann <kraxel@...> When building OVMF with TPM 1.2 support enabled do also include the configuration menu. Suggested-by: Stefan Berger <stefanb@...> Signed-off-by: Gerd

Modify SavePpRequest to look like its TPM 2 equivalent SaveTcg2PpRequest and have it submit the physical presence opcode to the PreOS function so that we can choose our own method for how to store it.

TPM 1.2 and TPM 2 share QEMU's PPI memory/device and for the TPM 2 code not to initilize over the TPM 1.2 initilization, leave the init function early without touching that memory. Cc: Gerd Hoffmann <

This series adds support for the full TPM 1.2 Physical Presence Interface (PPI) and activates the TPM 1.2 menu at the end. PPI is a prerequisite for the menu to work. The modifications to the original

Reviewed-by: Stefan Berger <stefanb@...>

The menu is there but it doesn't react to the selections, which I hadn't tested before. Maybe drop this patch in v3 and when I have time for looking into this I may post it again with fixes to actuall

You may have missed this one here: ./OvmfPkg/Microvm/MicrovmX64.dsc: DEFINE TPM_ENABLE = FALSE Tested-by: Stefan Berger <stefanb@...>

backward compatibility included -> support Reviewed-by: Stefan Berger <stefanb@...> Tested-by: Stefan Berger <stefanb@...>

2 more files would need this change: ./OvmfPkg/Microvm/MicrovmX64.dsc: DEFINE TPM_CONFIG_ENABLE = FALSE ./OvmfPkg/PlatformCI/ReadMe.md:| IA32 X64 Full | PEI-IA32 DXE-X64 | OvmfPkgIa32X64.dsc | SECURE_

Unfortunately this seems to be flawed on the TPM2_Quote level... Stefan

What I meant is the admin runs TPM2_PCR_Extend on PCRs 0-7 of the unused sha1 bank and extends it with known good values and has a log that goes with it and presents these to a validator along with th

Tcg2ConfigPeiCompat12.inf -> Tcg12ConfigPei.inf ? Stefan

You can still pretend that your system only has an active SHA1 bank and serve the fake log. Which part would raise suspicion about that on the side that looks at that trusted boot log, SHA1 PCR 0-7 st

The problem with this is that you can then fake measured boot on that system using it's unused SHA1 bank and extend into it whatever you want and create a fake log along with it and the quote is going

I see this also but when I get into Linux and run tpm2_pcrread I see the SHA1 bank active but not having received any PCR extensions from the firmware, which is not supposed to happen. So I think you

I think we should drop it. I will change this then for swtpm v0.7.0. Just in time... I wanted to make the release today but I'll delay that a bit then. Yes, please!

A few more comments to this series: - Is there a use case where TPM2_ENABLE_CONFIG is disabled, meaning where there should not be a TPM 2 menu entry? It's worth considering dropping this option becaus

I tested this on Fedora and attached a TPM 1.2 to the VM after a build **without** TPM1_ENABLE. When I run this here inside the VM cat /sys/devices/pnp0/00\:04/prcs I get measurements in PCRs 0-9 hint

FYI: TPM 2 does not provide backwards compatibility to TPM 1.2. TPM 1.2 is its own implementation that is incompatible with TPM 2. So the extension 'Compat12' is a bit odd in this case. Tested-by: Ste