Intel Management Engine Interface

We have addressed the issues raised on lkml after the first submission of the driver several weeks back and enhanced the driver with better sysfs support and additional device IDs to support more hardware with the ME firmware.

The "legacy" device is not really legacy as it is available in most recent desktops as a firmware options in the ME (AMT 1.0) and is still supported by Intel and many 3rd party applications; removing it will break many applications.

The Intel Management Engine Interface (aka HECI: Host Embedded Controller Interface ) enables communication between the host OS and the Management Engine firmware. MEI is bi-directional, and either the host or Intel AMT firmware can initiate transactions.

The core hardware architecture of Intel Active Management Technology (Intel AMT) is resident in firmware. The micro-controller within the chipset's graphics and memory controller (GMCH) hub houses the Management Engine (ME) firmware, which implements various services on behalf of management applications.

Some of the ME subsystems that can be access via MEI driver:

- Intel(R) Quiet System Technology (QST) is implemented as a firmware subsystem that runs in the ME. Programs that wish to expose the health monitoring and fan speed control capabilities of Intel(R) QST will need to use the MEI driver to communicate with the ME sub-system.
- ASF is the "Alert Standard Format" which is an DMTF manageability standard. It is implemented in the PC's hardware and firmware, and is managed from a remote console.

Most recent Intel desktop chipsets have one or more of the above ME services. The MEI driver will make it possible to support the above features on Linux and provides applications access to the ME and it's features.

---

index 9a91d9e..7b471bc 100644
@@ -1993,6 +1993,15 @@ M:	[email protected]
 L:	[email protected]
 S:	Maintained
 
+INTEL MANAGEABILITY ENGINE INTERFACE (HECI)
+P:	Anas Nashif
+M: 	[email protected]
+P:	Marek Dabek
+M:	[email protected]
+W:	http://www.openamt.org
+L:	[email protected]
+S:	Supported
+
 INTEL PRO/100 ETHERNET SUPPORT
 P:	John Ronciak
 M:	[email protected]

index b391776..469ad5b 100644
@@ -1063,6 +1063,7 @@ config DEVPORT
 	default y
 
 source "drivers/s390/char/Kconfig"
+source "drivers/char/heci/Kconfig"
 
 endmenu
 

index c78ff26..c5ca384 100644
@@ -105,6 +105,7 @@ obj-$(CONFIG_IPMI_HANDLER)	+= ipmi/
 
 obj-$(CONFIG_HANGCHECK_TIMER)	+= hangcheck-timer.o
 obj-$(CONFIG_TCG_TPM)		+= tpm/
+obj-$(CONFIG_HECI)              += heci/
 
 obj-$(CONFIG_PS3_FLASH)		+= ps3flash.o
 

new file mode 100644
index 0000000..46715de
@@ -0,0 +1,12 @@
+#
+# HECI device configuration
+#
+
+config HECI
+       tristate "Intel Manageability Engine Interface (HECI) Support"
+       depends on EXPERIMENTAL
+       help
+         The Intel Manageability Engine Interface driver allows
+         applications to access the  Active Management Technology 
+         firmware via host interface (as opposed to a network interface).
+

new file mode 100644
index 0000000..47b2217
@@ -0,0 +1,7 @@
+#
+## Makefile for the Intel MEI driver (heci)
+#
+
+obj-$(CONFIG_HECI) += heci.o
+
+heci-objs := heci_init.o heci_interface.o heci_main.o interrupt.o io_heci.o

Part of the diff is not shown here. View the raw message.

Can you please expand a bit on who on the host OS would actually communicate with the management engine? It looks like this driver just exports an interface to user space. What user space would use it and for what?

I would be definitely interested in a way to save oops information away using this. I remember you had a demo for this, is support for that coming soon?

-Andi

There are different ways you can connect to the Firmware and it all depends on the ME subsystem you want to communicate with.
For Intel AMT, you would use LMS (Local Manageability Service) which acts as a proxy for SOAP messages coming for management applications. LMS is available via
http://openamt.org/wiki/LocalManageabilityService.

The demo we had for storing kernel oops messages in the firmware used the AMT 1.0 interface (legacy) which allowed direct access to 3PDS using the MEI driver interfaces. In AMT 3.0 (current platforms) this has been disabled and only SOAP is possible which is why in the demo we changed the ME firmware to use AMT 1.0.

To have a feel for all of this, with many examples, samples and documentation you can download the AMT 3.0 SDK (google: intel amt sdk).

Anas

Ok but saving oops is such a useful facility that we'll probably need to think about implementing SOAP in the kernel. Before everybody complains that I went crazy: I suspect with some simplifying assumptions it could be made relatively straight forward code. In particular if one assumes no packets get lost then it would be possible to strip down TCP greatly (so it doesn't need to be much more complicated than netconsole) and I suspect a very minimal SOAP parser just for this application would be also possible.

I would be more interested right now how the kernel can use this without additional user space support. Any ideas on this?

-Andi

From: Andi Kleen <[email protected]>
Date: Tue, 11 Dec 2007 19:53:17 +0100

Ummm, no.

UDP is stateless, a stripped down copy of TCP we simply do not need. We also do not need XML in the kernel either.

If they want to support things like this they should do it in the firmware of the management entity like every other sane server platform does these days.

The console and OOPS messages should go over an extremely resilient transport which is as simple as possible which usually means shared memory or I/O memory with some simple handshake or doorbell. This gets it to the management entity board or whatever, and how it gets from there to the remote system is it's business not that of the kernel.

Not TCP, and definitely not this XML SOAP crap.

UDP? Anyways it turns out TCP is not even needed.

Even if it means you can get users to submit clear logged oopses out of many machines who hung silently before?

Sure most of the XML infrastructure that tends to be used in user space is pure bloat. But if you don't want universal interoperability and just for specific applications you'll essentially just have a few hardcoded strings that you'll write down some firmware interface and then a simple parser to read the results. Again that wouldn't be a generic XML parser, but just something tailored to the specific job.

I doubt it would be much worse code-wise than some of the more bizarre /proc ASCII interfaces.

They do -- the problem is that you need SOAP to talk the firmware. After reboot the user space can get it out of the firmware again.

With soap it would be a slightly more complicated handshake and a few hard coded text strings around the actual information. While that's not pretty if the result is worth it (and I think general oops logging would be worth a lot of things) that's not too bad.

-Andi

Actually no TCP/IP is needed here. Basically the MEI driver writes and reads the messages to/from the firmware. When communicating in-band using LMS, TCP/IP terminates at LMS and the messages are copied using MEI driver.

I will dig for some documents on that.

Anas

Ah that's good to know. I suspect the SOAP interchange could be stripped down a lot to make it reasonably simple; ideally with all strings just hardcoded somewhere. Would much parsing be needed?

-Andi

..

Sample code for storing a trace_back() would be much better.

-ml

Better just a patch that handles all oopses or perhaps better all printk output (meconsole?)

-Andi

There is a little problem: the driver doesn't work at all with the "64-bit kernel and 32-bit userspace" combination.

ioctl32(lms:7759): Unknown cmd fd(0) cmd(c0084800){t:'H';sz:8} arg(ffdfea44) on /dev/heci

Could you please fix it?

Alexander E. Patrakov