> On May 19, 2017, at 3:32 AM, Tomas Pilar (tpilar) <[email protected]> > wrote: > > The problem to solve is uniquely and persistently identifying which NICs are > grouped together in which host to a third party management system over LAN > during preboot in a reasonably secure way. > > If we use a random generated UUID every reboot, we're not persistent. If we > store the UUID across reboot, you could take the NIC out and move it to a > different host and keep the ID. So the idea was to construct it from either > the System UUID or using mobo/cpu serial numbers. >
The PXE network boot stack also uses the system UUID so the server can optionally send a custom image back to the system. So your requirement does not seem unreasonable. Thanks, Andrew Fish > Cheers, > > Tom > > On 18/05/17 19:26, Laszlo Ersek wrote: >> On 05/18/17 17:28, Tomas Pilar (tpilar) wrote: >>> This is what I was afraid of. I am writing an IHV network driver that >>> lives in optionROM. >> Out of curiosity, if you can share it, what do you need the sytem UUID >> in a network driver for? >> >> Thank you, >> Laszlo >> >>> Cheers, >>> Tom >>> >>> On 18/05/17 16:25, [email protected] wrote: >>>> It is a tricky problem. >>>> >>>> What I would like is for a new protocol to be defined, which should >>>> not rely on devices, to contain certain identifying information >>>> like this that would be useful to device drivers. It could be >>>> created early in DXE. >>>> >>>> What I fear is some future requirement that SMBIOS be made available >>>> at some definitive time pre-OS boot. >>>> >>>> You may have to get support from the BIOS vendor. If you are doing a >>>> driver for a particular system, that might not be too bad of a >>>> solution; but if you're trying to develop some generic driver, I >>>> don't have a good suggestion. >>>> >>>> Regards, >>>> Jim >>>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:[email protected]] On Behalf Of >>>> Tomas Pilar (tpilar) >>>> Sent: Thursday, May 18, 2017 10:14 AM >>>> To: Dailey, Jim <[email protected]> >>>> Cc: [email protected] >>>> Subject: Re: [edk2] SMBios configuration table not present until late >>>> stage of boot >>>> >>>> This does make sense. Do you have a suggestion how I would go about >>>> finding/creating a unique identifier for the system during preboot? >>>> >>>> Cheers, >>>> Tom >>>> >>>> On 18/05/17 16:11, [email protected] wrote: >>>>> Not a helpful comment, but I wanted to air my feelings on the topic: >>>>> >>>>> I view SMBIOS as data strictly for OS-level consumption and not for >>>>> any pre-boot code. I'm sure I'm in the minority, however. >>>>> >>>>> One of the problems is that the BIOS needs to have scanned all >>>>> devices/resources and perhaps executed a connect all before the >>>>> tables can be generated (or at least completed). >>>>> >>>>> Regards, >>>>> Jim >>>>> >>>>> -----Original Message----- >>>>> From: edk2-devel [mailto:[email protected]] On Behalf >>>>> Of Tomas Pilar (tpilar) >>>>> Sent: Thursday, May 18, 2017 10:01 AM >>>>> To: [email protected] >>>>> Subject: [edk2] SMBios configuration table not present until late >>>>> stage of boot >>>>> >>>>> Hi, >>>>> >>>>> I am trying to read the system UUID from the System Table (Type 1) in >>>>> the SMBios set of tables. I am doing this during DriverBinding.Start() >>>>> part of the UEFI_DRIVER initialisation. Unfortunately the >>>>> gST->ConfigurationTable only contains 6 tables and SMBios is not one of >>>>> them. >>>>> >>>>> Once I boot into UEFI shell or start a PXE booting process, the >>>>> gST->ConfigurationTable now contains 8 tables and SMBios is one of the >>>>> two new tables. If I however only boot to a HDD, this never seems to >>>>> happen. >>>>> >>>>> Can someone offer some insight why this might be so and how would I go >>>>> about forcing the platform to provide the SMBios in >>>>> gST->ConfigurationTable at a sensible point? >>>>> >>>>> Incidentally it seems ExitBootServices is not signaled on this platform >>>>> if the boot goes through to HDD either, which is another strange >>>>> thing ... >>>>> >>>>> Cheers, >>>>> Tom >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> [email protected] >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> [email protected] >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
