Re: Obtaining the UUID of the system for a PXE boot

Re: Obtaining the UUID of the system for a PXE boot

[Holger Goetz]

Hi,

ok posting on grub-devel list now. Further answer(s) at the bottom.


On 18.07.2013 17:35, Andrey Borzenkov wrote:
> I guess further discussion should be really moved to grub-devel
>
> В Thu, 18 Jul 2013 12:39:44 +0200
> Holger Goetz <holgerg@hgsys.de> пишет:
>
>> On 17.07.2013 16:31, Andrey Borzenkov wrote:
>>> On Wed, Jul 17, 2013 at 3:19 PM, Holger Goetz<holgerg@hgsys.de>  wrote:
>>>> Hello all,
>>>>
>>>> i've started to use grub.efi as boot loader for UEFI based systems and am
>>>> getting slowly familiar w/ grub2.Now i've come across a problem w/ assigning
>>>> individual boot configurations to target system identification.
>>>> The BIOS line of systems gets booted through pxelinux and get their PXE
>>>> configuration through files w/ names based on the individual UUID of the
>>>> system.
>>>> The same should be possible for UEFI booted systems, but i couldn't find a
>>>> way to get hold of the system-UUID yet. The MAC addresse(s) is/are not
>>>> available and possibly have changed since the definition of the
>>>> configuration, so even the lately introduced net_default_mac variable
>>>> doesn't work here. Having the UUID as unique system identifyer across NICs
>>>> which can be changed would be of big help.
>>>>
>>>> Any pointer/help would be greatly appreciated.
>>>>
>>> So, you need to fetch system GUID used by PXE, right? To be honest, I
>>> do not even know how (if it is possible at all) to obtain it. The only
>>> words about PXE GUID in EFI allow to switch between using GUID and MAC
>>> for client identification, but that's all:
>>>
>>> ===
>>> SendGUIDThis field is used to change the Client Hardware Address
>>> (chaddr) field in the DHCP and Discovery packets. Set to TRUE to send
>>> the SystemGuid (if one is available).
>>> ===
>>>
>>> Do you know how to get this information?
>>>
>>>
>> Hi Andrey,
>>
>> the system UUID is part of the SMBIOS structure which can be searched
>> between 0xf000 and 0x100000 in memory. It has a signature string "_SM_".
>> With in the SMBIOS table (memory block)  the table type 1 identifys the
>> UUID table and it contains a 16byte binary number which typically is
>> returned in a form like 00112233-4455-6677-8899-AABBCCDDEEFF. See the
>> SMBIOS specs here: http://www.dmtf.org/standards/smbios.
>>
>
> David Michael posted patch to grub-devel which provides access to SM
> BIOS information. You may be interested in checking to which extent it
> could be used in your case. Thread title is
>
> [PATCH/RFC] cpuid.c: Provide CPU model information
>
>> Also in the spec is some discussions around byte swappig parts of the
>> uuid, for consistency probably a byte by byte representation as a string
>> would be best.
>>
>> One implementation can be found in eg. syslinux's core/dmi.c - including
>> a rudimentary validation check.
>> Other implementations under Linux (eg. dmidecode) often take
>> /proc/efi/systab or /sys/firmware/efi/systab as starting points to the
>> SMBIOS structure, but that's obviously not available at the time grub
>> starts ;-)
>>
> I'm still not sure what exactly you need. There are three steps in
> booting grub2 over network
>
> 1. Firmware loads core.img using PXE. At this point it may provide MAC
> or GUID as client identification
>
> 2. core.img loads normal.mod which loads grub.cfg. This is done using
> location hardcoded in core.img.
>
> 3. Finally grub.cfg loads other files, loads OS kernel and executes it.
> It is using whatever features and commands grub2 provides and may
> decide location dynamically.
>
> Now, at which step exactly you need to know and use system GUID from SM
> BIOS?
>
> _______________________________________________
> Help-grub mailing list
> Help-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-grub

Hi Andrey,

i've checked David Michel's patch.
Yes it's towards the right direction. But it is 32bit only if i 
understand correctly, and it basically is a memory access to 
fixed/hardcoded  MEMORY address (0x80000001). to pick the veondor id and 
machine info.
I have only 64bit - UEFI here - therefore the approach w/ first 
searching the SMBIOS infoblock in memory is probably required. And then 
properly walk through the info-tables/blocks to get to the UUID entry. 
It doesn'T need to be a fixed info to be retrieved from the SMBIOS 
memory - maybe a generic function to query/search a specific entry and 
return that to be assigned to a variable would be more flexible.

You asked where exactly the uuid is needed - let me explain:
At stage 3 of your list aabove - where the default grub.cfg is 
interpreted. There a target machine specific grub.cfg file needs to be 
found on the tftpserver which carries different OS (Linux / Windows) and 
different (kernel) parameters on a per machine basis. This target 
specific grub.cfg file is named after the System UUID of the target. 
UUID is used as it's not known which NIC (so it's MAC) will be used to 
connect to the network, but it's UUID is. Having the UUID the matching 
cfg would be loaded from the tftpserver.

Thanks,
Holger

Re: Obtaining the UUID of the system for a PXE boot

[David Michael]

Hi,

On Fri, Jul 19, 2013 at 10:24 AM, Holger Goetz <holgerg@hgsys.de> wrote:
> Yes it's towards the right direction. But it is 32bit only if i understand
> correctly, and it basically is a memory access to fixed/hardcoded  MEMORY
> address (0x80000001). to pick the veondor id and machine info.

It's true that I've mostly been using the module on 32-bit virtual
machines, so it hasn't really been tested elsewhere.  However, I'm not
sure I understand what you mean by the hard-coded memory address.  The
first function grub_smbios_locate_eps searches for the SMBIOS entry
point structure as described in the spec.  The table entries are then
read at the table address found in the EPS, not a hard-coded location.

> I have only 64bit - UEFI here - therefore the approach w/ first searching
> the SMBIOS infoblock in memory is probably required. And then properly walk
> through the info-tables/blocks to get to the UUID entry. It doesn'T need to
> be a fixed info to be retrieved from the SMBIOS memory - maybe a generic
> function to query/search a specific entry and return that to be assigned to
> a variable would be more flexible.

The module's command-line interface does use a (dumb) query/search
method.  You can specify the desired entry's type and/or handle and
the data to retrieve from it.  For example the following command
prints the machine name (i.e. the string at offset 5 in an entry with
type 1).

        smbios -t 1 -s 5

I think you may have found the first patch I sent in that old thread,
which was for different functionality.  The SMBIOS module can be
downloaded from the list archive[1].

Unfortunately it doesn't have any convenient functions to output a
usable UUID.  It shouldn't take much to add one: the variable "entry"
in the "main" function is a pointer to the matched entry, so entry[8]
through entry[23] is the UUID in a call "smbios -t 1 ...".  I've
verified these bytes correspond to dmidecode output on my physical
hardware with the following.

        for i in 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
        do smbios -t 1 -b $i
        done

If the module isn't salvageable on UEFI, maybe I can send out an
updated version whenever I upgrade to such a system.

Thanks.

David

[1] https://lists.gnu.org/archive/html/grub-devel/2013-04/binx8am8MvVSh.bin

Re: Obtaining the UUID of the system for a PXE boot

[Vladimir 'φ-coder/phcoder' Serbinenko]

> If the module isn't salvageable on UEFI, maybe I can send out an
> updated version whenever I upgrade to such a system.
Change to retrieve SMBIOS on EFI is minor. See ACPI for comparison.

Re: Obtaining the UUID of the system for a PXE boot

[Holger Goetz]

On 19.07.2013 18:31, David Michael wrote:
> Hi,
>
> On Fri, Jul 19, 2013 at 10:24 AM, Holger Goetz <holgerg@hgsys.de> wrote:
>> Yes it's towards the right direction. But it is 32bit only if i understand
>> correctly, and it basically is a memory access to fixed/hardcoded  MEMORY
>> address (0x80000001). to pick the veondor id and machine info.
> It's true that I've mostly been using the module on 32-bit virtual
> machines, so it hasn't really been tested elsewhere.  However, I'm not
> sure I understand what you mean by the hard-coded memory address.  The
> first function grub_smbios_locate_eps searches for the SMBIOS entry
> point structure as described in the spec.  The table entries are then
> read at the table address found in the EPS, not a hard-coded location.
>
>> I have only 64bit - UEFI here - therefore the approach w/ first searching
>> the SMBIOS infoblock in memory is probably required. And then properly walk
>> through the info-tables/blocks to get to the UUID entry. It doesn'T need to
>> be a fixed info to be retrieved from the SMBIOS memory - maybe a generic
>> function to query/search a specific entry and return that to be assigned to
>> a variable would be more flexible.
> The module's command-line interface does use a (dumb) query/search
> method.  You can specify the desired entry's type and/or handle and
> the data to retrieve from it.  For example the following command
> prints the machine name (i.e. the string at offset 5 in an entry with
> type 1).
>
>          smbios -t 1 -s 5
>
> I think you may have found the first patch I sent in that old thread,
> which was for different functionality.  The SMBIOS module can be
> downloaded from the list archive[1].
>
> Unfortunately it doesn't have any convenient functions to output a
> usable UUID.  It shouldn't take much to add one: the variable "entry"
> in the "main" function is a pointer to the matched entry, so entry[8]
> through entry[23] is the UUID in a call "smbios -t 1 ...".  I've
> verified these bytes correspond to dmidecode output on my physical
> hardware with the following.
>
>          for i in 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>          do smbios -t 1 -b $i
>          done
>
> If the module isn't salvageable on UEFI, maybe I can send out an
> updated version whenever I upgrade to such a system.
>
> Thanks.
>
> David
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2013-04/binx8am8MvVSh.bin
>
Hi David,

you're right i had only found a small patch using cpuid   to retrieve 
vendor&model .

Looking at the smbios module briefly it looks very much like what i was 
hoping for.
I'll look into it in detail and will see what needs to be added for the 
UUID on a x86_64-efi system and let you know.

Thanks,
Holger

Re: Obtaining the UUID of the system for a PXE boot

[Holger Goetz]

Hi,

looks i could need some help here.

I've moved the smbios module from commands/i386 to commands and added 
some casts to make the compiler happy. As I need a x86_64-efi grub.
What i see now is that the "_SM_" signature is not found: "Failed to 
locate entry point structure"  some added grub_dprintf's show all zeros 
in the memory area.
Actually when i use the "dump" command to display the memory in the area 
that gets swiped (0xf0000..0x10000) it (also) only displays "00"s.
Is there some memory mapping required in x86_64 mode to access the 
memory area properly? I did cross check w/ the Linux kernel efi code and 
syslinux all basically do the same searching.

Thanks,
Holger



On 19.07.2013 18:31, David Michael wrote:
> Hi,
>
> On Fri, Jul 19, 2013 at 10:24 AM, Holger Goetz <holgerg@hgsys.de> wrote:
>> Yes it's towards the right direction. But it is 32bit only if i understand
>> correctly, and it basically is a memory access to fixed/hardcoded  MEMORY
>> address (0x80000001). to pick the veondor id and machine info.
> It's true that I've mostly been using the module on 32-bit virtual
> machines, so it hasn't really been tested elsewhere.  However, I'm not
> sure I understand what you mean by the hard-coded memory address.  The
> first function grub_smbios_locate_eps searches for the SMBIOS entry
> point structure as described in the spec.  The table entries are then
> read at the table address found in the EPS, not a hard-coded location.
>
>> I have only 64bit - UEFI here - therefore the approach w/ first searching
>> the SMBIOS infoblock in memory is probably required. And then properly walk
>> through the info-tables/blocks to get to the UUID entry. It doesn'T need to
>> be a fixed info to be retrieved from the SMBIOS memory - maybe a generic
>> function to query/search a specific entry and return that to be assigned to
>> a variable would be more flexible.
> The module's command-line interface does use a (dumb) query/search
> method.  You can specify the desired entry's type and/or handle and
> the data to retrieve from it.  For example the following command
> prints the machine name (i.e. the string at offset 5 in an entry with
> type 1).
>
>          smbios -t 1 -s 5
>
> I think you may have found the first patch I sent in that old thread,
> which was for different functionality.  The SMBIOS module can be
> downloaded from the list archive[1].
>
> Unfortunately it doesn't have any convenient functions to output a
> usable UUID.  It shouldn't take much to add one: the variable "entry"
> in the "main" function is a pointer to the matched entry, so entry[8]
> through entry[23] is the UUID in a call "smbios -t 1 ...".  I've
> verified these bytes correspond to dmidecode output on my physical
> hardware with the following.
>
>          for i in 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>          do smbios -t 1 -b $i
>          done
>
> If the module isn't salvageable on UEFI, maybe I can send out an
> updated version whenever I upgrade to such a system.
>
> Thanks.
>
> David
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2013-04/binx8am8MvVSh.bin
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>

Re: Obtaining the UUID of the system for a PXE boot

[Andrey Borzenkov]

В Tue, 23 Jul 2013 18:24:55 +0200
Holger Goetz <holgerg@hgsys.de> пишет:

> Hi,
> 
> looks i could need some help here.
> 
> I've moved the smbios module from commands/i386 to commands and added 
> some casts to make the compiler happy. As I need a x86_64-efi grub.
> What i see now is that the "_SM_" signature is not found: "Failed to 
> locate entry point structure"  some added grub_dprintf's show all zeros 
> in the memory area.
> Actually when i use the "dump" command to display the memory in the area 
> that gets swiped (0xf0000..0x10000) it (also) only displays "00"s.
> Is there some memory mapping required in x86_64 mode to access the 
> memory area properly? I did cross check w/ the Linux kernel efi code and 
> syslinux all basically do the same searching.
> 

You need to fetch SMBIOS table address from EFI system table. See as
example
https://git.ipxe.org/ipxe.git/blob/HEAD:/src/interface/efi/efi_smbios.c

You can use grub_machine_acpi_get_rsdpv2() as example implementation.
Just add SMBIOS GUID and any sanity checks as required.


> Thanks,
> Holger
> 
> 
> 
> On 19.07.2013 18:31, David Michael wrote:
> > Hi,
> >
> > On Fri, Jul 19, 2013 at 10:24 AM, Holger Goetz <holgerg@hgsys.de> wrote:
> >> Yes it's towards the right direction. But it is 32bit only if i understand
> >> correctly, and it basically is a memory access to fixed/hardcoded  MEMORY
> >> address (0x80000001). to pick the veondor id and machine info.
> > It's true that I've mostly been using the module on 32-bit virtual
> > machines, so it hasn't really been tested elsewhere.  However, I'm not
> > sure I understand what you mean by the hard-coded memory address.  The
> > first function grub_smbios_locate_eps searches for the SMBIOS entry
> > point structure as described in the spec.  The table entries are then
> > read at the table address found in the EPS, not a hard-coded location.
> >
> >> I have only 64bit - UEFI here - therefore the approach w/ first searching
> >> the SMBIOS infoblock in memory is probably required. And then properly walk
> >> through the info-tables/blocks to get to the UUID entry. It doesn'T need to
> >> be a fixed info to be retrieved from the SMBIOS memory - maybe a generic
> >> function to query/search a specific entry and return that to be assigned to
> >> a variable would be more flexible.
> > The module's command-line interface does use a (dumb) query/search
> > method.  You can specify the desired entry's type and/or handle and
> > the data to retrieve from it.  For example the following command
> > prints the machine name (i.e. the string at offset 5 in an entry with
> > type 1).
> >
> >          smbios -t 1 -s 5
> >
> > I think you may have found the first patch I sent in that old thread,
> > which was for different functionality.  The SMBIOS module can be
> > downloaded from the list archive[1].
> >
> > Unfortunately it doesn't have any convenient functions to output a
> > usable UUID.  It shouldn't take much to add one: the variable "entry"
> > in the "main" function is a pointer to the matched entry, so entry[8]
> > through entry[23] is the UUID in a call "smbios -t 1 ...".  I've
> > verified these bytes correspond to dmidecode output on my physical
> > hardware with the following.
> >
> >          for i in 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
> >          do smbios -t 1 -b $i
> >          done
> >
> > If the module isn't salvageable on UEFI, maybe I can send out an
> > updated version whenever I upgrade to such a system.
> >
> > Thanks.
> >
> > David
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2013-04/binx8am8MvVSh.bin
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
>