(The mailing list has been utterly broken for a while, so I don't expect this message to be distributed either. :()
On 01/15/15 18:43, James Bottomley wrote: > I've been playing with a set of tools (efitools, actually) to add > variable editing directly into flash files. What do you mean by "variable editing" and "adding it directly into flash files"? > Testing them, I discovered > that they don't work on Ovmf. Not because the tools have a problem but > because Ovmf ignores its flash variable area. Again, I don't understand. > This is a patch to fix > that (and remove a bit of unnecessary init code). It seems logical that > even the EmuVariable package should be able to use the existing variable > area in the flash file What do you mean by "flash file"? The NvVars file in the root directory of a FAT filesystem? > and it now allows me to pre-deposit secure boot > variables to create an ab-initio locked down image. Ie. you want to pre-populate an NvVars file with enrolled keys and distribute a VM disk that carries this NvVars file in the root dir of the ESP? > James Bottomley (1): > OvmfPkg: Initialize variables from Flash Image instead of creating > them anew > > OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c | 169 > +++++-------------------------- > OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf | 1 + > 2 files changed, 25 insertions(+), 145 deletions(-) Again, looking at the cumulative diffstat (because I can't look at anything else right now, since the mailing list is broken and 1/1 seems to be lost), I don't understand how this can fix anything beside the deprecated varstore emulation via the NvVars file. OVMF should not be passed to qemu (1.6+) with the -bios flag but with one of the following sets of options: (1) unified firmware image mapped as one pflash chip (contains OVMF binary and variable store): -drive file=.../OVMF.fd,if=pflash,format=raw,unit=0 or, more conveniently (and less securely due to image format auto-detection): -pflash .../OVMF.fd (2) split firmware images -- one pflash chip maps the executable read-only, another maps the varstore read-write: -drive file=.../OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=.../vms_copy_of_OVMF_VARS.fd,if=pflash,format=raw,unit=1 This set of options is preferred because it allows the host package manager to update OVMF_CODE.fd centrally, while each VM retains its own private variable store. (The OVMF_VARS.fd file coming out of the build is considered a template.) Libvirt supports both use cases: http://libvirt.org/formatdomain.html#elementsOSBIOS When you use -bios, no pflash chip is created, and non-volatile variable updates performed at OS runtime are preserved only in memory. If you warm-reboot the VM before powering it off, then the buffered variable updates are flushed to the NvVars file at boot time (that's what EmuVariableFvbRuntimeDxe + EmuVariableFvbLib do, together with PlatformBdsLib and NvVarsFileLib (both linked into Intel BDS)). If you power off the VM first, then such updates are lost. In addition, the logic that restores (deserializes) variables from the NvVars file at boot cannot set authenticated variables, so secure boot settings don't survive a reboot. However, when pflash is found, then EmuVariableFvbRuntimeDxe is inactive. Instead, QemuFlashFvbServicesRuntimeDxe provides the EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL that underlies the generic Fault Tolerant Write protocol that underlies the generic variable store drivers, and everything works as expected, including secure boot stuff. In short, I'm lost. :) Seeing your patch would probably help me understand your goal. Thanks Laszlo > > James > > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
