> > What I strongly object to is inventing a new bespoke way for the > firmware to make inferences about the capabilities of the image by > inspecting fields in the file representation of the image (which is > not guaranteed by EFI to be identical to its in-memory representation, > as, e.g., the PE/COFF header could be omitted by a loader without > violating the spec) > > As for the intermediate thing: yes, that would be a valuable thing to > have in OVMF (and I will gladly take EDK2 patches that implement > this). However, I'm not sure how you decide whether or not this thing > should be active or not, doesn't that just move the problem around? This does just move the problem around, but it makes correct behavior the default instead of silently ignoring most of the VM's memory and booting regularly. I have the driver mostly written to change the behavior to accept all by default unless a driver has been installed to set a particular boolean to make it not. Still that's yet another thing as you say. I agree with everyone that this situation just stinks. "Can't you just boot it?" was asked before, and yes we can, but at the scale of a CSP managing anybody's image uploads, that not-insignificant cost has to be paid by someone. It's a hard problem to route the image to the right kind of machine that's expected to be able to run it... it's a big ol' mess. One thing is for sure: these patches shouldn't be blocked by the "how do we detect it" question. I'm glad to see so much engagement with this problem, but I fear I might have delayed its progress towards a merge. I know AMD has a follow-up to add SEV-SNP accept_memory support to finish this all up. I'll try to get the ear of all the distributions that are tracking towards providing SEV-SNP-supported images for CSPs to get them on the release that includes these patches. I'll also see about upstreaming that EFI driver and EDK2 changes in case there's a slip in the kernel release and we need this workaround. -- -Dionna Glaze, PhD (she/her)
