Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
Arles Rodriguez
Total Points:
140
Status Points:
90
Green Belt
July 3, 2009 11:01 AM PDT
DMI UUID and AMT Intel Serial ID
Hi,

I am interested in make merge of DMI information and Serial Reported on intel AMT Device, I see that first digits of System ID don't match with the UUID reported reading dmi table values.

Machine model is DQ35JO.

Any help or similar observations must be greatly appreciated.

Thanks.
Lance Atencio (Intel)
Total Points:
5,692
Status Points:
5,192
Brown Belt
July 6, 2009 11:46 AM PDT
Rate
 
#1

Could you provide the numbers that are being returned?
There have been some byte swapping issues reported in the past.
thanks

Arles Rodriguez
Total Points:
140
Status Points:
90
Green Belt
July 7, 2009 3:02 PM PDT
Rate
 
#2 Reply to #1

Could you provide the numbers that are being returned?
There have been some byte swapping issues reported in the past.
thanks


There are the three first parts of serial appears in inverse order.

Example: intel amt web: bc19a334-5218-16ec-other_parts_of_serial_number
              dmi output:     34a319bc-1852-ec16-other_parts_of_serial_number

In effect they're appears like byte swapping, little endian bigendian maybe?

I read that some manufacturers take the three first part of this uuid and change byte order (littleendian), but this is reported on DMI 2.6, but my DMI version is 2.4.

By now, I will use the "Max Power" (The Simpsons method) and make some dark operations! 

Thanks by yours response.
 
Lance Atencio (Intel)
Total Points:
5,692
Status Points:
5,192
Brown Belt
July 7, 2009 5:07 PM PDT
Rate
 
#3 Reply to #2
Quoting - Arles Rodriguez


There are the three first parts of serial appears in inverse order.

Example: intel amt web: bc19a334-5218-16ec-other_parts_of_serial_number
              dmi output:     34a319bc-1852-ec16-other_parts_of_serial_number

In effect they're appears like byte swapping, little endian bigendian maybe?

I read that some manufacturers take the three first part of this uuid and change byte order (littleendian), but this is reported on DMI 2.6, but my DMI version is 2.4.

By now, I will use the "Max Power" (The Simpsons method) and make some dark operations! 

Thanks by yours response.
 


Yep, that looks like the bug.

Here is some code that Randy has written to deal with this:
// data is a array if 16 bytes (AMT returned GUID)
byte[] data;

//re-arrage the first 7 bytes returned from AMT
byte t = data[3];
data[3] = data[0];
data[0] = t;
t = data[2];
data[2] = data[1];
data[1] = t;
t = data[5];
data[5] = data[4];
data[4] = t;
t = data[7];
data[7] = data[6];
data[6] = t;

// now you have a correctly formatted GUID
Guid guid = new Guid(data);
rogerb
Total Points:
1,355
Status Points:
855
Brown Belt
July 8, 2009 8:51 AM PDT
Rate
 
#4 Reply to #3

Yep, that looks like the bug.

Here is some code that Randy has written to deal with this:
// data is a array if 16 bytes (AMT returned GUID)
byte[] data;

//re-arrage the first 7 bytes returned from AMT
byte t = data[3];
data[3] = data[0];
data[0] = t;
t = data[2];
data[2] = data[1];
data[1] = t;
t = data[5];
data[5] = data[4];
data[4] = t;
t = data[7];
data[7] = data[6];
data[6] = t;

// now you have a correctly formatted GUID
Guid guid = new Guid(data);

Hi Lance,

I think that you need to very careful before you declare that there is a bug in the code. The definition of the bytes in the GUID goes all the way back to AMT 2.0, and the tools have been correct in the past. By definition, the GUID is {DWORD-WORD-WORD-WORD-[12 chars]} the dwords and words are stored in native format, that being little-endian on an Intel platform. So, if you just read out the GUID as a set of bytes, you will have to re-arrange the first four parts of the GUID to match the definition. This came up as an issue in some mobile and desktop systems running AMT 2.0 and AMT 2.5 a couple of years ago. Therefore, you need to be very careful about saying that some code is in error on this matter.

Regards,
Roger
Lance Atencio (Intel)
Total Points:
5,692
Status Points:
5,192
Brown Belt
July 8, 2009 9:10 AM PDT
Rate
 
#5 Reply to #4
Quoting - rogerb
Hi Lance,

I think that you need to very careful before you declare that there is a bug in the code. The definition of the bytes in the GUID goes all the way back to AMT 2.0, and the tools have been correct in the past. By definition, the GUID is {DWORD-WORD-WORD-WORD-[12 chars]} the dwords and words are stored in native format, that being little-endian on an Intel platform. So, if you just read out the GUID as a set of bytes, you will have to re-arrange the first four parts of the GUID to match the definition. This came up as an issue in some mobile and desktop systems running AMT 2.0 and AMT 2.5 a couple of years ago. Therefore, you need to be very careful about saying that some code is in error on this matter.

Regards,
Roger

Thanks for the background Roger.

Sounds like this is more of a behaviour that may be not be expected.

Arles Rodriguez
Total Points:
140
Status Points:
90
Green Belt
August 5, 2009 12:32 PM PDT
Rate
 
#6 Reply to #5
Thanks all for your replies.

I'll continue using my max power, playing with the bytes of uuid.


Quoting - Lance Atencio (Intel)

Thanks for the background Roger.

Sounds like this is more of a behaviour that may be not be expected.
Andrew Schiestl (Intel)
Total Points:
3,473
Status Points:
2,973
Brown Belt
August 5, 2009 5:11 PM PDT
Rate
 
#7 Reply to #6

This is one of those interesting issues that actually predates and is separate from AMT (I've seen it come up in VM's sometimes as well).  It sounds like you had already seen some of the background when you looked online, but you can find some more details on the background in the DMTF spec for SM BIOS (http://www.dmtf.org/standards/published_documents/DSP0134_2.6.1.pdf ).

The short answer is that the IETF standard for UUID (RFC4122) recommends network byte order for all fields, but the defacto standard in much of the PC industry has been to use little-endian for the first 3 fields (the exact fields are mentioned in the spec).  For instance, if  you can make a WMI call to get the UUID on that system (it's the uuid property of the Win32_ComputerSystemProduct class), you'd see the same ordering that you saw in the webui.  The only place I've seen in AMT where the other ordering of the UUID is seen is at the very low level that typically isn't exposed in a human readable way.

 



Intel Software Network Forums Statistics

8445 users have contributed to 31553 threads and 100398 posts to date.
In the past 24 hours, we have 10 new thread(s) 30 new posts(s), and 43 new user(s).

In the past 3 days, the most popular thread for everyone has been Lost in MKL The most posts were made to TBB on linux segfaulting The post with the most views is Hi,if you were using imsl yo

Please welcome our newest member nonamez