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. 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
