Hacker News Reader

Comment by gnu8 | Hacker News Reader

I would like to know how the ME shares the NIC with the user OS on these systems. Do they have a completely separate interface that somehow uses the same physical port? Do the drivers from the two operating systems cooperate? Do they have one MAC address or two? What happens if the user installs a PCI NIC and doesn’t plug in the onboard interface?

View on HN

The hardware has the ability to tag packets with certain contents - this is used for more interesting Wake-on-LAN policies (eg, rather than requiring a magic packet, you could have a web server that aggressively suspends and then gets automatically woken when there's an incoming packet to port 80 or 443). In the AMT case, it identifies incoming packets that are aimed at the AMT ports and passes those off to the ME rather than the OS. If you want to speak to AMT from the host OS, you install an app that listens to those ports on localhost and then tunnels the traffic through the HECI interface instead. There's only one IP address and one MAC address, and it's limited to built-in Intel NICs.

It definitely only works with certain Intel NICs. It doesn't require OS cooperation because the main purpose of AMT is to recover a broken OS. I think the NIC effectively has two host interfaces so that one can be used by the OS and the other can be used by the ME. Due to network authentication and such I think the same IP and MAC address is shared by the OS and AMT which is of course a rampant layering violation.

> It definitely only works with certain Intel NICs.

Not really doubting you as that kind of stands to reason to me, but is there any proof of this? The whole thing seems opaque.

I think the general idea is that the purpose of having networking in the ME is to enable certain features, which are documented to only work with certain Intel NICs. Of course if you are paranoid, you would not trust this to stop a determined attacker.

Will it have access to a wifi card? Only Intel?

Yes, AMT works over Intel WiFi.

Raising yet more questions about how AMT participates in enterprise WiFi authentication schemes. My laptop at work has a computer certificate which works for the OS, but how does AMT have credentials or even know which SSID to associate with?

This is all available in the Intel AMT documentation. While the implementation is closed-source and opaque, this isn't some magic functionality, it's a product that businesses want and use.

If the OS is running, wireless AMT forwards packets through the OS driver; it's cooperative (unlike the wired AMT, which always exists at a higher level than the OS, because it has features like resetting a crashed OS).

If the OS isn't running, you provision the AMT with WiFi credentials for the AMT host, using a tool. If you want, you can use the Local Manageability Service (LMS) tool to automatically forward credentials from the OS to the AMT, otherwise, you can install specific profiles.

I have bitter memories about AMT and all this "remote management by Intel" from the old days.

When I'd built my first home server/NAS I wanted remote control but I didn't want to pay for hardware with real IPMI/iLO/..., so I choose desktop motherboard from Intel with Q35 chipset (it was time when Z45/Q45 was cutting edge and 35th series was previous generation). NIC was Intel's one too, I think it was legendary PRO/100, not 1G yet.

I was VERY disappointed to discover, that I didn't get remote console and/or remote serial port with ME/AMT at all, that it i not true AMT in desktop motherboards, even with Q chipset.

Reply on news.ycombinator.com