On Mon, Oct 18, 2021 at 2:08 PM Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: > > Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx> writes: > > > 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 <ayala.beker@xxxxxxxxx> > > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx> > > 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.
