On 01/15/15 22:32, James Bottomley wrote: > On Thu, 2015-01-15 at 20:27 +0100, Laszlo Ersek wrote: >> (The mailing list has been utterly broken for a while, so I don't expect >> this message to be distributed either. :() > > Yes, I'm still waiting for the [PATCH 1/1] to show up .. > >> 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"? > > The variable area of the flash file can contain variables and values. > It's one mechanism for pre-setting secure boot variables ... there are > others; for instance Quark does it in the platform data of the > QuarkPlatformPkg > >>> 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. > > Ovmf when brought up with the EmuVariableFvb driver will not use the > variable section of the fd file. > >>> 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? > > No, the flash file is the fd file that you run the emulation from > consisting of a bunch of firmware volumes. One of the firmware volumes > is the variables one. > >>> 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? > > Effectively, but I want the mechanism to work for real flash files ... I > just want to be able to test it in Ovmf. > >>> 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.) > > OK, so I'm developing tools for real flash images ... I'm actually > working on the Galieo at the moment. I'll check this out because it may > help me if Ovmf better emulates flash storage. I think the tools still > work ... they're optimised for single image flash, but there's no reason > they won't work with multiple volumes.
Okay, I understand it now (I also skimmed patch 1/1). Roughly, you have a tool (a POSIX utility) that opens a flash image, locates the firmware volume with the variables in it, and manipulates the variables. http://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/commit/?id=ede47075ba54791245e3bbf20a7e740eb1d91b33 In edk2 the format is implemented by the variable driver, and documented in the Intel whitepaper A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKI Part III - Variable Variable Storage Format As far as I understand, your tool is destined to work on pristine flash images, ie. not on live flash, or files dumped from live flash (which could be in a corrupt state --> section "Fault Tolerant Write" in the whitepaper). You'd like to take the pristine flash image that's the result of a build process, and patch some variables into it before writing it to an actual flash chip (or passing it to an emulator). Okay. In OVMF, this firmware volume has size 56K, it's defined (preformatted) in "OvmfPkg/VarStore.fdf.inc". It is followed by some other things related to FTW, but you don't care about that. Okay. When qemu runs OVMF, the variable store is mapped at 4GB-2MB (or 4GB-1MB, dependent on the firmware image size that you select at build time). When you use -pflash, whatever is there in the backing file simply appears at the right address in the guest-phys address space; done. (It doesn't matter in this regard whether you use a unified or a split build -- in the unified build, the varstore is the first 56K of the 2MB OVMF.fd file that gets mapped at 4GB - 2MB; in the split build, the varstore is the first 56K of the VM-specific copy of the 128K OVMF_VARS.fd file that gets mapped at 4GB - 2MB.) However, if you use -bios (which requires a unified, 2MB OVMF.fd file): the lowest 56K of the file is mapped to the same address, and indeed the contents are visible in the address space; however, since it is backed by ROM, not a pflash chip, QemuFlashFvbServicesRuntimeDxe will print "FD behaves as ROM", and will not become active. Instead, EmuVariableFvbRuntimeDxe will become active. The latter driver indeed doesn't care about the 4GB-2MB .. 4GB-2MB+56KB range (speaking in specifics now). What happens is, very early during boot, the ReserveEmuVariableNvStore() function in PlatformPei allocates a chunk of memory. At the first (cold) boot of the VM, this memory will be empty, and when EmuVariableFvbRuntimeDxe looks at it, it will contain no headers. Then EmuVariableFvbRuntimeDxe places the headers in it, and uses this chunk of memory as buffer for the variable store for the rest of time (the 4GB-2MB .. 4GB-2MB+56KB area is unused). After a reboot, the headers will be there. Your patch changes the initialization such that when this chunk of memory, allocated by PlatformPei, is empty & lacks the headers, EmuVariableFvbRuntimeDxe no longer populates it with just the headers & structure, but actually copies the 4GB-2MB .. 4GB-2MB+56KB range into it. Because, that's where the data you have prepared with your tool is mapped, by -bios. At the first sight it seems reasonable, but EmuVariableFvbRuntimeDxe is deprecated at this point (Jordan, please feel free to chime in). I'd rather not see a driver being patched that I recommend users to stay away from. Instead, please try out your utility on a unified OVMF.fd file (or even better, on a VM-specific private copy of OVMF_VARS.fd, under the split scheme), and simply pass those as pflash chips (see the options in my previous email). If your tool formats the varstore area correctly, it should work out of the box (because the file in question is mapped as a pflash chip and that chip carries live contents), and no OvmfPkg patch should be necessary. Can you please try that? Thanks, Laszlo ------------------------------------------------------------------------------ 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
