> > > > 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> > > --- > > v2: fix a few warnings raised by the different bots > > v3: rewrite the commit message > > v4: put the debugfs content in a different patch > > --- > > I think I did all you wanted, I can understand if this series doesn't get merged > for 5.14, but I really would like to make sure that we are ready to apply this > after the merge window. > If you're happy with this, great. If not, let me know so that I can fix what you > want to see fixed. > FYI - there is also the patch for mei that I don't send for review because it's > already ACK'ed by Greg, and there is another patch that I haven't sent yet > because it relies on a cfg80211 patch that is now in > net-next: 358ae88881adc3ac1544104272eb7e9408f80b39 > If you merge net-next, I'll be able to rebase and send this one as well. > Merge window is now closed, can we make progress here? Thanks
