bhyve: enable TPM2 passthrough

[corvink]

Summary

Description:
Add cmdline option for TPM emulation

How to use TPM2 passthrough:
Add -l tpm2,passthru,/dev/tpmX to your bhyve cmd line.

bhyve -c 2 -m 4G -A -H -P -w \
  -s 0,hostbridge \
  -s 4,virtio-blk,/root/win/win10.img \
  -s 5,virtio-net,tap10 \
  -s 20,xhci,tablet \
  -s 29,fbuf,tcp=0.0.0.0:5900,wait \
  -s 31,lpc \
  -l com1,stdio \
  -l bootrom,/usr/local/share/uefi-firmware/BHYVE_CODE.fd \
  -l tpm2,passthru,/dev/tpm0 \
  win10

Tested Scenarios:

OS
Ubuntu	Working
Windows	Working

Tested with Intels fTPM device.

[darkfiberiru_gmail.com]

I understand this would probably be a thing for someone else to implement later. But allowing backing by https://github.com/stefanberger/swtpm would be a nice feature.

[corvink]

In D32961#744093, @darkfiberiru_gmail.com wrote:

I understand this would probably be a thing for someone else to implement later. But allowing backing by https://github.com/stefanberger/swtpm would be a nice feature.

Thanks for that hint.
I'd like to implement a swtpm in the future. It will require some more work to do. Don't know when I'm able to do it.

This patch allows a guest direct access to the physical TPM. It doesn't emulate the TPM.

[corvink]

• split into multiple commits

[markj]

usr.sbin/bhyve/bhyve.8

544

usr.sbin/bhyve/bhyve_config.5

143

This is typically /dev/tpm0?

147

Which versions are supported?

usr.sbin/bhyve/pci_lpc.c

273

Why do we hang the TPM device off of the LPC? arm64 won't have an LPC driver, but there's no reason to exclude TPM emulation/passthrough on arm64 AFAIK...

[corvink]

• improve man page

[corvink]

usr.sbin/bhyve/pci_lpc.c

273

I just needed a place to add it. Afaik, some TPMs are attached to the LPC. Where would you like to add this option?

[corvink]

@jhb @markj Any additional comments?

[markj]

usr.sbin/bhyve/bhyve_config.5

146

What are the valid types?

[corvink]

• mention supported tpm types in man page

[corvink]

usr.sbin/bhyve/pci_lpc.c

273

@jhb @markj Where should we hang off the TPM device?

[jhb]

I think to address Mark's concern you would just need to have a tpm_init with the new code currently added to lpc_init. I would perhaps suggest that we need a init_devices function called from main that would call init_pci and then this new tpm_init. Eventually we might want to have a linker set or C++ constructors or something for device models to register init routines, but for now just adding a static call to tpm_init would be ok.

[corvink]

• create a init_devices and init_tpm function

[markj]

In D32961#944105, @jhb wrote:

I think to address Mark's concern you would just need to have a tpm_init with the new code currently added to lpc_init. I would perhaps suggest that we need a init_devices function called from main that would call init_pci and then this new tpm_init. Eventually we might want to have a linker set or C++ constructors or something for device models to register init routines, but for now just adding a static call to tpm_init would be ok.

The latest revision of the patch gets us part of the way there, but TPM config is still a subtree of the LPC config. I am not sure what the right solution is. For arm64 I have simply been extending the -o option, so one writes -o console=stdio -o bootrom=u-boot.bin, for example. Maybe we should start adopting that for amd64 as well, handling backward compatibility? In any case, I suppose this doesn't need to block the change.

usr.sbin/bhyve/bhyverun.c

1215 ↗

(On Diff #126028)

The opening brace should be on its own line.

1493 ↗

(On Diff #126028)

IMHO there is not much use in adding this function. The perror() call below does not tell you whether init_pci() or init_tpm() failed. I would just inline it.

If there is a particular reason init_pci() needs to be called first (I don't see one?), it should be documented in a comment.