TCG2 Configuration not appear on Win 11 guest (VirtualBox 7.0.9r157775)

[fth0]

VirtualBox provides a virtual TPM (with the help of libtpms) and a virtual NVRAM including a UEFI Variable Store. From my POV, your questions are rather Windows-related questions than VirtualBox-related questions, and I don't have the necessary knowledge to answer them. I'd suggest to investigate the issues as if they happened on a Windows host without VirtualBox.

[Chooseme]

Oracle VM VirtualBox

[Chooseme]

Oracle VM VirtualBox

[fth0]

No, they are not windows related. The option is not appearing in UEFI and UEFI is controlled and created by Virtualbox not Windows.

Agreed. If it is about the TCG2 Configuration not being visible in the VirtualBox UEFI BIOS Device Manager, then it's probably VirtualBox-related. If it's about BitLocker keys not being in the TPM any more, then it's unclear. Sorry for any confusion!

Do you know who from the team would be knowledgable in this topic?

No. But there have been TPM-related bugfixes in VirtualBox 7.0.10 and 7.0.12, so I wouldn't use any older VirtualBox version than 7.0.12.

[Chooseme]

Oracle VM VirtualBox

[fth0]

Please provide a zip file containing a new VBox.log, the .vbox and .nvram files.

[Chooseme]

Oracle VM VirtualBox

[fth0]

I use 7.0.12

The VBox.log file provided today begs to differ!

Please try VirtualBox 7.0.12. The TPM-related bugs had to do with the TPM device not showing up in the Windows 11 guest, so the bugfixes could also matter in your case (although you perhaps didn't use a saved state).

[Chooseme]

Oracle VM VirtualBox

[fth0]

Thanks for the log files! They indeed show no relevant differences to me, but I couldn't know that beforehand and I wouldn't start analyzing TPM-related issues with any older VirtualBox version anyway.

One thing that I noticed from the VBox.log file is that you're running VirtualBox under the Hyper-V hypervisor (NEM mode, green turtle), which unnecessarily slows down any VirtualBox VM. Some Windows users are in that situation since they installed Windows on their hosts, some users get into it after some Windows update enforcing it. Do you know if you were running under Hyper-V before your problem started?

I'll see if I can make a few experiments with your .nvram file at the weekend.

[Chooseme]

Oracle VM VirtualBox

[fth0]

I made some experiments with results similar to yours:

Taking your Bit-work.nvram file, a working Win11.nvram file and combining their TpmEmuTpms/permall and efi/nvram files, the VirtualBox UEFI BIOS seems to reject the contents of the TpmEmuTpms/permall file.

Looking into the VirtualBox source code of the virtual TPM device and the UEFI BIOS TCG2 components only revealed their complexity to me, so you'd probably need somebody with the necessary knowledge and debugging skills to investigate what's rejected for which reason.

I use 7.0.12 and the bug is still there

So far, I don't think that it's the same bug, which was easy to reproduce and easy to understand (after the bugfix ). Your issue has the same effect, though, so there could be a connection. Which VirtualBox version did you use when creating the VM (and afterwards)? Did you use a saved state at any time?

Edit:
Looks like I got somewhat confused about another TPM-related bug, which was introduced in VirtualBox 7.0.10 and solved in VirtualBox 7.0.12. The VM couldn't be restored from a saved state, and because of the not-restored virtual TPM the VM didn't even reach the UEFI BIOS.

[Chooseme]

Oracle VM VirtualBox

[Chooseme]

Oracle VM VirtualBox

[fth0]

Searching the source code is broken as you cant even find TCG2 configuration menu code.

That's what I meant when talking about complexity. I do understand many parts of the VirtualBox source code, but the UEFI BIOS is its own kind of a beast. Definitely nothing for "1 minute". SCNR

The other complex part is libtpms, which seems to be modeled after the TPM 2.0 specs (> 900 pages!), and contains the code that handles the contents of the permall file (< 10 kB). I found the code importing all the little bits and pieces, but that's perhaps nowhere near the error. That's where a debugging session would be a possible next step (but not for me ATM). And debugging sessions can take a long time ...

I also looked at a hexdump of your and my permall file, but there weren't any obvious errors, so it's about the details.