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

554

usr.sbin/bhyve/bhyve_config.5

143

This is typically /dev/tpm0?

147

Which versions are supported?

usr.sbin/bhyve/pci_lpc.c

267

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

267

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

267

@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

1211

The opening brace should be on its own line.

1474

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.