Hi, TL;DR I don't need AMI support, but need direct kernel boot support for confidential computing use case. Direct kernel boot is currently one of the popular solutions in confidential computing use case to measure boot elements like kernel. We actually used it internally in our initial PoC to support SEV-SNP in nova which I plan to contribute to upstream next cycle (after I complete the SEV-ES support work during this cycle). There are some active deployment activity in this area to implement secured vTPM which allows measured boot without direct kernel boot, but this work is still under very active development. I don't have the full understanding about the current issue, but I'm hoping that we can keep the direct kernel boot for some time until we get a better method acceptable for confidential computing use case. Note that we do not use AMI images but just raw (or qcow2) image with raw kernel image and raw randisk image associated (by kernel-id property and ramdisk-id property) to use direct kernel boot. Thank you, Takashi Kajinami On 7/26/24 02:13, Dan Smith wrote:
Hi all,
tl;dr: We really need ops feedback about any direct need to retain this feature.
Since the early days, Nova has supported the notion of "direct linux kernel boot" (with libvirt/kvm at least). This means each bootable image in Glance is actually three parts: a disk image, a ramdisk image, and a kernel. Booting the instance involves putting the kernel and ramdisk into memory in a special way that the kernel can immediately start booting instead of doing things like running the bootloader like a normal system does. This is present in Nova because of long-ago Amazon compatibility, as this is how Xen paravirt guests used to work for them. I think that in the early days of Nova, compatibility with the _actual_ images used on Amazon was important, but I think that is no longer something we need to care about today, just as we have deprecated EC2 API compatibility. It should also be noted that some of it is broken, and the recent CVE fixes have broken it like three times in the last 30 days. Continuing to support it makes the code more complex and fragile, and arguably less secure.
So, I'm asking for operator feedback on this question:
Do you need this feature, and if so, why?
Speak now or expect to see it deprecated for removal very soon.
Thanks!
--Dan