From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 52C2C21A16EC2 for ; Fri, 19 May 2017 03:32:18 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id BA3FB6007B; Fri, 19 May 2017 10:32:15 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 276BB80056; Fri, 19 May 2017 10:32:15 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx3-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BC6F860061; Fri, 19 May 2017 10:32:10 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 19 May 2017 11:32:06 +0100 To: Laszlo Ersek , CC: References: <1548dc48-890d-29e0-0bdc-5df3ce545e5b@solarflare.com> <83202bed-050e-cf5d-a3f3-13b8a83ad739@solarflare.com> <800d8d0d8b4841eaa43d75d0939b6521@ausx13mps335.AMER.DELL.COM> <8aa8fe53-b9f5-64c7-66ba-b18555087a99@solarflare.com> <0739bc9e-bb5a-cd9f-918a-46d95a0c91ca@redhat.com> From: "Tomas Pilar (tpilar)" Message-ID: <5d3798d5-764c-6e0e-b9d9-fe41668ba983@solarflare.com> Date: Fri, 19 May 2017 11:32:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <0739bc9e-bb5a-cd9f-918a-46d95a0c91ca@redhat.com> X-Originating-IP: [10.17.20.51] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23078.003 X-TM-AS-Result: No--24.786400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1495189935-b3CwTYKtEyvO Subject: Re: SMBios configuration table not present until late stage of boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 10:32:18 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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. 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, Jim.Dailey@dell.com 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:edk2-devel-bounces@lists.01.org] On Behalf Of >>> Tomas Pilar (tpilar) >>> Sent: Thursday, May 18, 2017 10:14 AM >>> To: Dailey, Jim >>> Cc: edk2-devel@lists.01.org >>> 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, Jim.Dailey@dell.com 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:edk2-devel-bounces@lists.01.org] On Behalf >>>> Of Tomas Pilar (tpilar) >>>> Sent: Thursday, May 18, 2017 10:01 AM >>>> To: edk2-devel@lists.01.org >>>> 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 >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel