DMI UUID and AMT Intel Serial ID

[Arles_Rodriguez]

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_A_Intel]

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

[Arles_Rodriguez]

Quoting - Lance Atencio (Intel)

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 firstparts 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 threefirst part ofthis 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_A_Intel]

Quoting - Arles Rodriguez

There are the three firstparts 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 threefirst part ofthis 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);

[RBens2]

Quoting - Lance Atencio (Intel)

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_A_Intel]

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]

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_S_Intel2]

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 backgroundin 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'sthe 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.