Hi, > > Moving away from pflash for efi variable storage would cause alot of > > churn through the whole stack. firmware, qemu, libvirt, upper > > management, all affected. Is that worth the trouble? Using pflash > > isn't that much of a problem IMHO. > > Agreed. pflash is a bit clunky but not a huge problem atm (although > setting up and tearing down the r/o memslot for every read resp. write > results in some performance issues under kvm/arm64) > > *If* we decide to replace it, I would suggest an emulated ROM for the > executable image (without any emulated programming facility > whatsoever)
Sure. > and a paravirtualized get/setvariable interface which can > be used in a sane way to virtualize secure boot without having to > emulate SMM or other secure world firmware interfaces. Suggestions how to do that best? The only option I can see is moving the variable policy processing to the host, so any variable update requests are checked even in case the guest OS bypasses the firmware (which it can easily do when we don't have SMM mode to restrict access to the paravirtual efi variable service device). take care, Gerd
