containers
Replace qboot with rust-hypervisor-firmware as guest firmware
In libkrun-sev, we package a custom qboot, kernel, and init. To support upstream kernels with TEEs, we require more firmware support. Investigate the use of rust-hypervisor-firmware as libkrun's firmware.
@slp I wonder if this will slow down boot times. Does the qemu-microvm type use OVMF/EDK2?
FWIW TDX is built with OVMF in mind, so this would be useful in that sense i.e. less overhead on our end to keep up with changes in qboot
TDX does require ACPI and PCI to be supported, so that might be one of the "customized" bits you were mentioning
@slp I wonder if this will slow down boot times. Does the qemu-microvm type use OVMF/EDK2?
A little bit, but compared with the amount of time required to inject the payloads and accept the pages, it's barely significant.
FWIW TDX is built with OVMF in mind, so this would be useful in that sense i.e. less overhead on our end to keep up with changes in qboot
TDX does require ACPI and PCI to be supported, so that might be one of the "customized" bits you were mentioning
Does TDX require ACPI and PCI, or are those requirements of OVMF for TDX?
All in all, I think we should evaluate the costs of supporting OVMF for libkrun, in both SNP and TDX variants, versus extending qboot to support booting the primary and secondary processors without patches. I wouldn't be surprised if the latter ends becoming cheaper, given that half the work is already there and what we need from the FW is just some very minor functionality.
@slp I wonder if this will slow down boot times. Does the qemu-microvm type use OVMF/EDK2?
A little bit, but compared with the amount of time required to inject the payloads and accept the pages, it's barely significant.
FWIW TDX is built with OVMF in mind, so this would be useful in that sense i.e. less overhead on our end to keep up with changes in qboot TDX does require ACPI and PCI to be supported, so that might be one of the "customized" bits you were mentioning
Does TDX require ACPI and PCI, or are those requirements of OVMF for TDX?
As far as I understand it, they are requirements of OVMF for TDX. I was debugging this with Intel, and they suggested it should be possible to modify the TDX device initialization code to not use them and get it to work.
All in all, I think we should evaluate the costs of supporting OVMF for libkrun, in both SNP and TDX variants, versus extending qboot to support booting the primary and secondary processors without patches. I wouldn't be surprised if the latter ends becoming cheaper, given that half the work is already there and what we need from the FW is just some very minor functionality.
All in all, I think we should evaluate the costs of supporting OVMF for libkrun, in both SNP and TDX variants, versus extending qboot to support booting the primary and secondary processors without patches. I wouldn't be surprised if the latter ends becoming cheaper, given that half the work is already there and what we need from the FW is just some very minor functionality.
If we can support running unmodified kernels this way, then I'm all for it.