Re: [PATCH v6 2/7] iwlwifi: mei: add the driver to allow cooperation with CSME

On Mon, Oct 18, 2021 at 2:08 PM Kalle Valo [off-list ref] wrote:

Emmanuel Grumbach [off-list ref] writes:

quoted

CSME in two words
-----------------
CSME stands for Converged Security and Management Engine. It is
a CPU on the chipset and runs a dedicated firmware.
AMT (Active Management Technology) is one of the applications
that run on that CPU. AMT allows to control the platform remotely.
Here is a partial list of the use cases:
* View the screen of the plaform, with keyboard and mouse (KVM)
* Attach a remote IDE device
* Have a serial console to the device
* Query the state of the platform
* Reset / shut down / boot the platform

Networking in CSME
------------------
For those uses cases, CSME's firmware has an embedded network
stack and is able to use the network devices of the system: LAN
and WLAN. This is thanks to the CSME's firmware WLAN driver.

One can add a profile (SSID / key / certificate) to the CSME's OS
and CSME will connect to that profile. Then, one can use the WLAN
link to access the applications that run on CSME (AMT is one of
them). Note that CSME is active during power state and power state
transitions. For example, it is possible to have a KVM session
open to the system while the system is rebooting and actually
configure the BIOS remotely over WLAN thanks to AMT.

How all this is related to Linux
--------------------------------
In Linux, there is a driver that allows the OS to talk to the
CSME firmware, this driver is drivers/misc/mei. This driver
advertises a bus that allows other kernel drivers or even user
space) to talk to components inside the CSME firmware.
In practice, the system advertises a PCI device that allows
to send / receive data to / from the CSME firmware. The mei
bus drivers in drivers/misc/mei is an abstration on top of
this PCI device.
The driver being added here is called iwlmei and talks to the
WLAN driver inside the CSME firmware through the mei bus driver.
Note that the mei bus driver only gives bus services, it doesn't
define the content of the communication.

Why do we need this driver?
--------------------------
CSME uses the same WLAN device that the OS is expecting to see
hence we need an arbitration mechanism. This is what iwlmei is
in charge of. iwlmei maintains the communication with the CSME
firmware's WLAN driver. The language / protocol that is used
between the CSME's firmware WLAN driver and iwlmei is OS agnostic
and is called SAP which stands for Software Abritration Protocol.
With SAP, iwlmei will be able to tell the CSME firmware's WLAN
driver:
1) Please give me the device.
2) Please note that the SW/HW rfkill state change.
3) Please note that I am now associated to X.
4) Please note that I received this packet.
etc...

There are messages that go the opposite direction as well:
1) Please note that AMT is en/disable.
2) Please note that I believe the OS is broken and hence I'll take
   the device *now*, whether you like it or not, to make sure that
   connectivity is preserved.
3) Please note that I am willing to give the device if the OS
   needs it.
4) Please give me any packet that is sent on UDP / TCP on IP address
   XX.XX.XX.XX and an port ZZ.
5) Please send this packet.
etc...

Please check drivers/net/wireless/intel/iwlwifi/mei/sap.h for the
full protocol specification.

Arbitration is not the only purpose of iwlmei and SAP. SAP also
allows to maintain the AMT's functionality even when the OS owns
the device. To connect to AMT, one needs to initiate an HTTP
connection to port 16992. iwlmei will listen to the Rx path and
forward (through SAP) to the CSME firmware the data it got. Then,
the embedded HTTP server in the chipset will reply to the request
and send a SAP notification to ask iwlmei to send the reply.
This way, AMT running on the CSME can still work.

In practice this means that all the use cases quoted above (KVM,
remote IDE device, etc...) will work even when the OS uses the
WLAN device.

How to disable all this?
---------------------------
iwlmei won't be able to do anything if the CSME's networking stack
is not enabled. By default, CSME's networking stack is disabled (this
is a BIOS setting).
In case the CSME's networking stack is disabled, iwlwifi will just
get access to the device because there is no contention with any other
actor and, hence, no arbitration is needed.

In this patch, I only add the iwlmei driver. Integration with
iwlwifi will be implemented in the next one.

Co-Developed-by: Ayala Beker <redacted>
Signed-off-by: Emmanuel Grumbach <redacted>

s-o-b missing from Ayala, same problem also in other patches in this
patchset.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

I fixed all the comments and pushed to a branch in our tree to get a
0-day run on it.
One question though: there is currently a (small) diff between
iwlwifi-next and wireless-driver-next that makes this series conflict.
This is because of a fix that was applied on wireless-drivers-next
directly and Luca hasn't merged your tree back to his yet.
I can send v7 on either code base you like.
I think 0-day tests iwlwifi patches against iwlwifi-next but I am not sure.
Luca is on vacation until next week.

Any option you'll choose will be fine by me. Just let me know.