From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9384E21A16EC2 for ; Fri, 19 May 2017 13:48:05 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4C443D955; Fri, 19 May 2017 20:48:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D4C443D955 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D4C443D955 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-127.phx2.redhat.com [10.3.116.127]) by smtp.corp.redhat.com (Postfix) with ESMTP id A35AC5C552; Fri, 19 May 2017 20:48:03 +0000 (UTC) To: "Tomas Pilar (tpilar)" , Jim.Dailey@dell.com Cc: edk2-devel@lists.01.org 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> <5d3798d5-764c-6e0e-b9d9-fe41668ba983@solarflare.com> From: Laszlo Ersek Message-ID: Date: Fri, 19 May 2017 22:48:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5d3798d5-764c-6e0e-b9d9-fe41668ba983@solarflare.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 19 May 2017 20:48:05 +0000 (UTC) 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 20:48:05 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/19/17 12:32, Tomas Pilar (tpilar) 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. I think this platform smbios DXE driver might suffer from the (apparently) common problem "let me do all my stuff in a ReadyToBoot callback". To me this seems like just another example why that cannot work, generally speaking -- a bunch of DXE drivers waiting for "everything else" to complete their work, intending to get a "full" system description as the last agent, and then to install stuff solely for the OS. This results in unspecified behavior if at least two agents with inter-dependencies do this. Instead, the platform smbios DXE driver should have a depex on the smbios protocol, and at dispatch time, it should install all the tables at once (from its entry point) that are possible to compute & install right then. I would assume type 1 is such a table. (just my opinion) Thanks Laszlo > 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 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel