Support for Intel Active Management Technology over wireless in Linux

[Emmanuel Grumbach <egrumbach gmail com>]

Hello,

I am Emmanuel Grumbach from the wireless group at Intel.
We added support for Intel Active Management Technology over wireless in Linux
and wanted to touch base with the NetworkManager's community because
this feature
needs integration with the NetworkManager.

Let me first explain what this technology provides.
In a nutshell, AMT takes the WLAN NIC when you still don't have OS
(while you reboot e.g.) and you can have a KVM for the BIOS configuration,
attach a storage device remotely to install an OS etc...
You can configure AMT to connect to WLAN when the system is in S3 or
even in S5 and then you can talk to AMT while the system is powered
down, and wake it up or query the system for other stuff. All this
doesn't need OS integration since the OS doesn't exist at that point.
Meaning that for all this, nothing is needed in the userspace nor in kernel
space.

OS integration is needed when when the OS boots and you still want
your KVM session to work. For that, we implemented the iwlmei kernel
module. It allows to forward traffic that runs on the host to AMT, meaning
that AMT uses the device under the OS's control to send / receive traffic.
Of course, there are also control messages going on between the
host and AMT. Such control messages are:
1) host is now connected to this profile
2) host is now disconnected (and optionally plans to reconnect quickly because
it's roaming).
3) host is now in airplane mode
4) host is asking to get the device although AMT is connected to an AP
4) AMT is now connected to an AP

 When the host wants to use the device, it first needs to ask the device
from AMT which may or may not grant the request.
This is why we added a reason to the HW RFKill state. We could be in a
state where the device exists, yet it is not available to the host for now and
we first need to request it. The best way to reflect this is to report RFKILL to
the stack. In order to allow the userspace to differentiate between a classic
RFKILL and a case where the NIC is under AMT"s control, we added a reason
to the HW RFKILL state.

All this can sound quite cumbersome, why would AMT keep the device and force
the host to use a specific protocol to request the device before
letting the host use it.
After all, the host can always request the device, so it doesn't add
any "security" or
anything.
The answer is in the description of the flow below.

Imagine we have an IT personnel working on a system and the IT engineer opened
a KVM session using AMT. He now reboots the machine. During the reboot, he wants
to configure the BIOS etc.. All this is possible because AMT will use
the wireless device
to connect to an AP letting him see the display of the system during
those steps. The KVM
works on top of TCP and the TCP connection has a short timeout (3 seconds).
Now the OS boots and it takes the device, it doesn't know that someone
has a TCP connection
active, the OS starts a full scan, (which typically takes 4 / 5
seconds). The host may trigger
a few more scans, and then, it'll connect to some AP. The TCP connection broke.

This is why we want to implement the following flow:
1) the wifi driver (iwlwifi) starts and sees the AMT doesn't want to let
it use the device because AMT is maintaining an active TCP connection
2) iwlwifi reports RFKILL (the host can't be using the NIC which
is now used by AMT)
3) iwlwifi gets information about the AP that AMT is connected to
and it'll pass this info to the NetworkManager
4) NetworkManager checks that it has the credentials to connect to
that profile
5) NetworkManager tells iwlwifi / iwlmei that it has the right
credentials and that it is ready to connect. It then adds the
profile to the supplicant and limits the scan frequencies to frequency
on which AMT is connected. Same for the BSSID.
6) iwlmei tells AMT that the host is ready to connect and it asks ownership
on the device
7) AMT releases (from a HW point of view) the ownership
8) iwlmei gets ownership and releases the RFKILL state
9) All the connection process including DHCP happens very quickly (~500ms)
10) The host is now connected, and the TCP connection is preserved so
that the IT personnel having a KVM session to this machine just saw a
small glitch.

What is required to implement in the NetworkManager?

1) NM needs to notify the kernel to what AP it is connected (to
include the WPA version). Unfortunately, we can't do
this from the kernel, although in case there is a strong objection
from the maintainers of the NM, I guess we can
compromise here.
2) NM needs to understand the RFKILL state with the NOT_OWNER reason (see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/rfkill.h#n101)
and know not
to expect anything from the device in this state.
3) NM needs to know how to get info about the AP AMT is currently connected to.
4) In case the device is in RFKILL NOT OWNER, NM needs to configure
the network in the wpa_supplicant with
a specific scan_freq_list and bssid to speed up the connection process.
5) NM must be able to modify the network configuration in the
wpa_supplicant so that it'll be able to roam
when the TCP connection is torn down.
6) NM needs to know how to request ownership on the device when it
came to the conclusion it'll know how
to connect to the same AP AMT is connected to.
7) NM must configure the airplane mode state.

All this is done through Intel vendor specific commands over netlink.

Disclaimer: This feature is available only on vPRO Platforms.

Question to the NM maintainers:
Would you consider merging patches that would implement this?
Do you see any blocker to implement this?
Any recommendation for the implementation?

Thanks for reading this and looking forward to hearing from you :)

Emmanuel Grumbach
egrumbach gmail com