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,502
Status Points:
5,002
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,502
Status Points:
5,002
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,315
Status Points:
815
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,502
Status Points:
5,002
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,413
Status Points:
2,913
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

8286 users have contributed to 31231 threads and 99107 posts to date.
In the past 24 hours, we have 7 new thread(s) 31 new posts(s), and 43 new user(s).

In the past 3 days, the most popular thread for everyone has been comparison cilk++, openmp, pthreads first results The most posts were made to comparison cilk++, openmp, pthreads first results The post with the most views is Very amusing...  Escalated as

Please welcome our newest member titanius.anglesmith