public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>, Jim.Dailey@dell.com
Cc: edk2-devel@lists.01.org
Subject: Re: SMBios configuration table not present until late stage of boot
Date: Fri, 19 May 2017 22:48:02 +0200	[thread overview]
Message-ID: <d6a3ca9b-ffff-4775-ac41-29d38951f76c@redhat.com> (raw)
In-Reply-To: <5d3798d5-764c-6e0e-b9d9-fe41668ba983@solarflare.com>

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 <Jim_Dailey@Dell.com>
>>>> 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



      parent reply	other threads:[~2017-05-19 20:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 15:00 SMBios configuration table not present until late stage of boot Tomas Pilar (tpilar)
2017-05-18 15:11 ` Jim.Dailey
2017-05-18 15:13   ` Tomas Pilar (tpilar)
2017-05-18 15:25     ` Jim.Dailey
2017-05-18 15:28       ` Tomas Pilar (tpilar)
2017-05-18 17:22         ` Andrew Fish
2017-05-18 18:26         ` Laszlo Ersek
2017-05-19 10:32           ` Tomas Pilar (tpilar)
2017-05-19 17:36             ` Andrew Fish
2017-05-19 20:48             ` Laszlo Ersek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6a3ca9b-ffff-4775-ac41-29d38951f76c@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox