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

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-10-01 at 20:52 +0200, Jose Ignacio Tornos Martinez wrote:
> Hi Johannes,
> 
> > I don't _think_ it does that. It does behave a bit differently for MFP,
> > but that's wrt. management frames.
> 
> Good to know. I will re-test with just MFP re-enabled and no data
> keys to hardware, adding more debug logging to understand where
> data gets stuck. Something else must have been wrong in my v1 test.
> 
> > Fundamentally, in this case the driver (even mac80211) shouldn't install
> > (data) keys to hardware.
> 
> Ok
> 
> > I'd need to sit down and (re-)derive that, but I don't recall it being
> > particularly tricky - just boils down to the various dependencies
> > between features.
> 
> Ok, I can assume there are no other dependencies to start with.

A-MSDU size is definitely dependent on PTK since A-MSDU splitting
requires hardware crypto, and otherwise the RX buffers aren't big
enough (by default, but it's not worth the complexity, and people won't
want to do big allocations anyway). There may eventually be a way out
with split RBs but we don't (yet) implement that in the driver.

EHT requires MFP and beacon protection, beacon protection requires
checking in firmware since firmware reacts to beacon frames.

6 GHz was documented in the code.

MLO needs EHT and then transitively that was disabled.

The biggest question then remains what MFP gaps you create with this. I
_think_ you might even have to install random keys to the firmware, but
... then maybe it wouldn't even pass certain frames to the driver? I'm
not sure you want to accept a loss of MFP security.

johannes