On 07/06/17 20:30, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Jason Dickens > had to walk into mine at 10:31:18 on Thursday 06 July 2017 and say: > >> All, >> >> I'm trying to understand why the secure boot variables (PK, KEK, db, >> etc) when using the OVMF build are not retained across reboot? It >> seems that this code uses roughly the same SetVariable, GetVariable2 >> approach as say the PlatformConfig uses to store screen resolution >> (which is retained). Additionally, the NvVars file is being at least >> touched by the secure boot configuration. So why are none of the keys >> retained on the next reboot? > > If you're running OVMF in the QEMU simulator, and you're using the > -bios option, try using the -pflash option instead. > > I know that when using -bios, QEMU only pretends to allow writes to > the firmware region, and if you stop QEMU all changes are discarded. > The same might be true if you just trigger a hard reboot in the > simulator too. > > If you use -pflash instead, your changes will be saved. Note that this > means your OVMF image will be modified, so keep a copy of the original > elsewhere so that you can start over fresh again if you need to. > > (Unfortunately I don't think OVMF has a "load factor defaults" option > in its internal menus.)
Libvirt has a good pile of functionality built on top of the split image that I described earlier. For example: In /etc/libvirt/qemu.conf, you can provide an "nvram map", listing several different firmware binaries, with a matching variable store template for each. (Different fw binaries may require different varstore formats: for example, you can run aarch64 guests in emulation (TCG) mode, using the ArmVirtQemu edk2 platform as your virtual firmware, and x86_64 guests in hw virtualization (KVM) mode, using OVMF as your virtual firmware, on the same x86_64 host. These firmwares expect a different flash layout, so they need different varstore templates. Another example is that you can build OVMF with 1M, 2M or 4M (unified) image sizes, and the 4M layout uses a different (much larger) varstore -- so the template is different for that fw binary.) When defining a new VM, a subset of the libvirt client tools allows you to pick a specific firmware binary. And when starting a VM that has no varstore file under /var/lib/libvirt/qemu/nvram, libvirt will map its fw binary to the matching varstore template, and instantiate the VM's own varstore from the template. As a side benefit, if you are fed up with the current contents of your varstore, simply shut down the VM, and delete its varstore file from under /var/lib/libvirt/qemu/nvram. When you next start the VM, libvirtd will re-create the varstore from the pristine template. Libvirt is an insanely powerful and great project -- I can praise it without holding back, as I personally almost never contribute to it --, and I do all my virt development (incl. edk2 development) exclusively with guests that are managed by libvirt. While the QEMU project is similarly powerful and great :) , the QEMU command line is *not* a human interface. (This is not to say that libvirt only composes command lines for the VMMs that it supports -- it does a whole lot of other host management too, such as SELinux labeling of images, setting up migration across the network, configuring virtual networks, handling assigned physical PCI devices, and much more.) Thanks, Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
