Re: [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hi Johannes,

Based on the discussion around v1, I tried to prepare a more complete
proposal addressing the concerns raised there (AddBA, CSA, robust
action frames). I understand I may have gone too broad and missed
some aspects of how encryption offload works internally, without
access to firmware documentation it is difficult to get everything
right.

Just to clarify a few points, WoWLAN was intentionally kept disabled
in the patches (both mvm and mld paths), precisely because it requires
all traffic via firmware crypto during suspend. IGTK handling was not
changed either, as mac80211 already handles it in software. A-MSDUs
are not directly MFP-related, fair point, but they were part of the
same commit being reverted, because patch 2 and patch 3 are just
reverting some parts of the FIPS disabling to try to get it working
again under the exception.

On the specific patches:

Patch 2: In v1, I only re-enabled MFP_CAPABLE without passing keys
to firmware, the result was connection but no data traffic. That is
why I added key delivery in v2. Is it possible to keep software
crypto for data while having a functional connection, or does the
firmware require keys installed to pass frames? This would help me
understand the correct approach.

Patch 3: I can narrow this to the minimum needed. Some features
(EHT, 6GHz) depend on MFP so I included them, but I agree it
could be more selective.

Patch 4: The intent was host-side crypto for management frames via
SW_MGMT_TX (same mechanism as ath9k, rtw89, etc.), but I understand
this depends on how patch 2 is resolved.

Ultimately, I just want to fix a problem affecting our customers who
are interested in keeping WiFi working, accepting that some lower-level
management frames are not FIPS-compliant while the important part for
them, data encryption, is. The default behavior is maintained, this
is only allowed if the exception is explicitly configured. This was
working before the commits and our customers already have this
hardware deployed.

I don't want to bother you with more patches without guidance. I can
try to engage Intel on this, but any help, recommendation on the right
approach to try to solve this in some way would be appreciated.

Thanks

Best regards
Jose Ignacio