Sent from my iPhone
> On Nov 1, 2013, at 1:40 AM, Laszlo Ersek <ler...@redhat.com> wrote: > >> On 10/28/13 22:27, Jordan Justen wrote: >> https://github.com/jljusten/edk2.git ovmf-nvvars-v1 >> >> This series implements support for QEMU's emulated >> system flash. >> >> This allows for persistent UEFI non-volatile variables. >> >> Previously we attemptedto emulate non-volatile >> variables in a few ways, but each of them would fail >> in particular situations. >> >> To use: >> * QEMU version 1.1 or newer is required without KVM >> * KVM support requires Linux 3.7 and QEMU 1.6 >> * Run QEMU with -pflash OVMF.fd instead of -L or -bios >> or use OvmfPkg/build.sh --enable-flash qemu ... > > That means that persistent variables will be written back to OVMF.fd > (also in accordance with patch 3/8), doesn't it? > > Would it be possible, in general, to split off the variable storage, and > keep OVMF.fd read-only, and continue to specify it with -bios? > > Because, if OVMF.fd is read/write on the host filesystem, and > non-volatile variables are written into it, then: > > - With N guests that want to have independent sets of variables, the > user needs N copies of OVMF.fd. That per se is not a big problem, but > > - Upgrading OVMF to a newer build, while preserving each guest's > variables is (a) messy -- needs fiddling with the guts of the > preexistent OVMF.fd files, (b) an O(n) operation -- each guest's copy > needs to be updated separately. > > A separate, per-guest, "data only" flash, and a read-only-as-before OVMF > binary would be more flexible for Linux distributions. > > I'm not suggesting that it should be done in this series, I'm just > asking about the possibility. (For example I have no idea what happens > on a physical host to someone's NvVars when the UEFI BIOS is reflashed > to a newer build.) > On a real platform the FLASH update utility is smart and deals with this. You could also have MAC addresses , serial numbers, PXE UUID, and other per system data that was programmed at the factory that really needs to be preserved. > I'd be glad to work on this later on (but I'll need guidance). > A separate FD would be the easiest way to deal with this. You could have an installer step in the build that only copies over the NV storage FD if it does not exist. You guys should also implement the PXE UUID as a different UUID per installation. > Thanks > Laszlo > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
