On 11/01/13 21:46, Andrew Fish wrote:
> 
> On Nov 1, 2013, at 2:34 AM, Andrew fish <af...@apple.com
> <mailto: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));

The official / committed OvmfPkg code has no support for SMBIOS. The
code you're referring to (function NetLibGetSystemGuid()) should return
EFI_NOT_FOUND early, before reaching the CopyMem() above, right after
EfiGetSystemConfigurationTable().

The SMBIOS patches that I had posted earlier for OVMF
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3037> implement
the following logic for the UUID field in the Type 1 record:

(1) If qemu provides a complete Type 1 table (including the UUID field),
install it.

Otherwise, use a default (built-in) OVMF table, with the following
overrides:

(2a) Load the UUID from qemu, from the the dedicated UUID fw_cfg file,
(2b) then, if qemu provides a field-level override for Type1.UUID, use
that instead.

> It should be unique per platform.

The universally used management toolstack for qemu, libvirt, generates a
unique UUID for each virtual machine at creation time, and this UUID
remains persistent for the VM. (It is saved in the VM config XML file).

When starting the VM, libvirt passes this UUID to qemu on the command
line, and then it is available to OVMF too.

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

According to the above, the UUID is VM specific, permanent, stored on
the host side in the VM config XML, and independent of the OVMF build.
The host administrator can edit the UUID if necessary. I believe that
should mostly accommodate your recommendation, shouldn't it?

Thank you!
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

Reply via email to