Understanding ME's role on systems that do not implement MEBx

[BPaxt]

Greetings.

What purpose does Intel AMT stuff serve, imbedded into system BIOSes, when the OEM decides not to fully implement? Why do they bother putting ME firmware on their chips at all? Why do they bother offering updated drivers and sometimes updated ME versions via a BIOS upgrade?

I was initially curious about two Asus and MicroStar based systems I had to work on, but in researching this, apparently there are plenty of vendors who decide to not provide the MEBx interface. There is no MEBx header upon booting, no Ctrl-P works, and trying to access tcp/19662 gets no response. I have no idea why they decide to not implement the MEBx interface, when they integrate ME into their system BIOS packages, and continue to provide updates to both the drivers and firmware! I have gotten half-assed answers from both vendors, so I decided to come here and ask.

Again, I am confused beyond the ability to ask a questions correctly. Please bear with my rambling.

Since in modern EFI BIOS setups allocated on your common 8Mbit SPI Flash ICs, this is all very structured. A block for the system BIOS, a block for the GbE firmware, and so forth. And a specific address range associated with ME firmware. I have flashed different versions into a running system BIOS by only flashing that range, probably the same way the proper Intel FWUpdLcl utility works. If I run MeInfoWin, it identifies the version I just flashed, and my system still operates correctly. (Granted, this is an OEM BIOS with that region extracted from the firmware BIN, not directly using an Intel ME firmware update image.)

I want to see if, without any assistance or approval from the vendor, if we can enable MEBx. I'm sure ME is already there. There's probably a single byte toggle or something equally easy to enable access. But I could be wrong, the vendors are only flashing it onto their BIOS chips because it's required due to chipset licensing and only enabling the parts necessary for compliance, and none of the code to hook to the hardware devices is there.

Also I understand Intel's position on information disclosure, so if this is something we don't discuss in public, please say so. Besides, reading compiled machine code isn't as difficult as it used to be. Although in paging through the ME firmware hex, I see embedded x86 executable code. No decoding necessary. I'll guess it's the html server and the various configuration utilities that a fully-deployed and activated MEBx uses. And that's my point. The firmware is there. I want to enable it. Why won't said vendor(s) enable it? Choice? Cost? Complexity? Customers? I really want to know.

Sidenote: in trying to research this, I found many, many posts by people that think AMT is bad/evil/wrong. Really?

I'm sure I just scared all the conspiracists: "He wants to voluntarily activate the Intel spyware!!? Is he crazy?!"

Yes. So thanks for reading the ramblings of a crazy person.

And thanks in advance for any illumination provided... it's dark over here.

[Alan_A_Intel]

Bill_P,

The short answer is, the decision whether or not to enable ME is completely up to the OEM. That said, if the OEM is updating both OS drivers and ME firmware, then there is a good possibility AMT is simply disabled in the BIOS menu.

[DWest7]

Bill_P raises an interesting point and one I have been wondering about, why add the ME on consumer boards if there is no way to leverage it?

I have an Asus P8Z68-V LX motherboard at home and noticed that it has the ME interface, however I have yet to find any way to access it.

Why have the ME and even provide drivers and firmware updates if there is no way of using it?

Am I missing something?

[Alan_A_Intel]

Dave_W,

OEM's including Asus use a standard driver package which includes the Management Engine Interface. They use this package for all their motherboards even those that don't support vPro. The Asus P8Z68-V LX motherboard uses the Z68 chipset which does not support vPro.

The best place to verify if your CPU and chipset selection are vPro capable is at Intel's ARK website.

http://ark.intel.com/ http://ark.intel.com

[BPaxt]

Guys,

Thanks for the replies, but it's clear you do not know the answer(s) either! I'm not saying there's a conspiracy theory here, but there's more to it than this.

Whether or not a chipset revision officially supports AMT/ME, they are bothering to not only include it in their system BIOS and future revisions, but provide updated ME software for those exact systems that supposedly do not have any ME enabled?

No one, not Asus, not MSI, not anyone ever... would bother to do this for no reason. It involves work, and by definition, work sucks. No one would bother interfacing to this code, especially having end users flashing BIOS chips thereby risking failed flashes and RMAs that ultimately the vendor has to pay for... no. I don't believe that for a second. So what's going on? Why do they implement it, when in fact they don't implement it? It makes no sense.

Hmm. Thinking aloud here. What if... it's partial? Maybe 3rd party or certain tools still work? Since I see $METDT references and a large block of binary code associated with TDT (Theft Deterrence Technology aka AT-p) in the ME BIOS region, so perhaps something like Computrace could access that select bit of ME?

Gates help me. I am going to go a bit OCD on this. I will find out. I need to.

Thanks in advance for any assistance to the cause!