On Nov 1, 2013, at 2:34 AM, Andrew fish <af...@apple.com> wrote:
> 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.
>
>
This is the UUID I was talking about. It is in the SMBIOS TYPE 1 record.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
CopyMem (SystemGuid, &Smbios.Type1->Uuid, sizeof (EFI_GUID));
It should be unique per platform. The idea is the PXE Server can make a policy
decision on what image to serve back to a particular machine. So for example if
you had a bunch of OVMF instances set up for testing, you could teach the PXE
Server the UUID of a specific machine and serve back a specific OS (or even
version of an OS) installer in response to the PXE boot to automate testing.
Folks have botched this in the real world and return back the same UUID for a
class of machines, so it would be good to make sure each OVMF instance is
unique, but does not change from build to build. So this UUID would be
something that would get preserved like the NV Storage, so probably good to
design in a solution for the UUID when fixing the NVRAM storage issue.
Thanks,
Andrew Fish
------------------------------------------------------------------------------
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
