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. hum we should discuss this future but im not sure if we should proceed with SEV-SNP enablement before
On Fri, 2024-07-26 at 18:01 +0900, Takashi Kajinami wrote: that is completed. with that said if the request for SEV-SNP is done via a trait on the image combined with the exisitng image property for memory encycpition it may be workable given the direct kernel boot functionality is also expressed on the image. that woudl be a pretty big limitation however for that feature. direct kernel boot obviosly has lifecycle implciationf for the guest i.e. you cant just do a dnf or apt update in existign instnaces. it forces you to rebuild to update the kernel for security fixes for example. that is fine if your applciations are stateless and cloud native where all data is storead on cidner volumes and the root image is just packageing the aplicaiton but for any enterpirse usecases that are less cloud aware it would basiclaly make the SEV-SNP feature unusable if it was a hard requirement. lets take that discussion elsewhere however and keep this thread focused on dan's original question.
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.
direct kernel boot is slightly easier to support then AMI the short version is AMI is not really well defiend format and how its expressed in glance is problematic. none of the tools we use (qemu-img,file, the format inspector) actully recognise ami/aki/ari as they are not really file format they are just lables for the types of content conatined in a uec/ami "image" that makes validating very complex. the long version is the uec/ami iamges are just a tar with a file contianing a root files system, a kernel and a ramdisk the issue is that each of those 3 embeded files can be in any format. typically the root file system image is a copy of a block device with a partitaion table and a file system liek what you woudl get form "dd if=/dev/sda of=root.img". [10:48:51]➜ file -z * cirros-0.6.2-x86_64-blank.img: Linux rev 1.0 ext3 filesystem data, UUID=f1511162-06fb-4482-9dab-9a0c76633fb2, volume name "cirros-rootfs" (large files) cirros-0.6.2-x86_64-initrd: ASCII cpio archive (SVR4 with no CRC) (gzip compressed data, max compression, from Unix) cirros-0.6.2-x86_64-vmlinuz: Linux kernel x86 boot executable bzImage, version 5.15.0-71-generic (buildd@lcy02-amd64-044) #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023, RO-rootFS, swap_dev 0XB, Normal VGA the problem that creates for us is we cant really validate the content of these images for saftey as a result. at least not without coming to an agreement about what format are valid. to that end in light of the recent CVEs we would like to start moving away form ami/ari/aki and moving towards glance having explcit disk formats that match reality. im proxying some of the converstaion i have had with dan on this topic but for exmaple the root disk image cirros-0.6.2-x86_64-blank.img shoudl really be disk-format=GPT i.e. declaring to glance that this iamge contains a gpt partition table to be bootable by qemu the initrd needs to be in cpio format and can optionally be compressed cirros-0.6.2-x86_64-blank.img so instead of ari we shoudl be uploadign that as disk-format=cpio for the kernel we can also have a disk-format=linux-kernel instead of aki. before doing that however we wanted to know if we need to maintain support for direct kernel boot or if this is a legacy functionality we coudl remove form our codebase. what we want to move away form is treating anything we dont recognise as raw as that makes it very hard to properly harden ourselves form any future CVEs. the more strict we can be with the content of images in glance the more secure openstack will be going forward.
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