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

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

> With the minimum changes on top of the fips_allows() infrastructure
> (patch below), I have bidirectional data working with SW crypto.
> mac80211 handles CCMP encryption/decryption on the host, firmware
> has no data keys.

No keys at all, but yeah.

What are you testing with now? Still MFP?

> However, I had to disable RX AMPDU aggregation to make RX work.
> Without PTK in firmware, firmware does not set the correct bits
> in the Block Ack bitmap, since it cannot validate the received
> frames. The AP assumes frames were not received, retransmits,
> and eventually gives up. TX AMPDU works fine because the AP has
> the keys and sends correct BA back to the STA.

That doesn't really make sense. How can TX A-MPDU work when you have
MFP, this was the bit you disabled earlier even with all the other work?
And the firmware has to send the AddBA request, so that can't make it
through??

> Disabling RX AMPDU forces individual frame ACKs, which work at
> the PHY level without keys. The throughput cost is significant:
> ~12-30 Mbps instead of ~500 Mbps with HW crypto.

That almost seems low (11g maxed out at ~24 Mbps with 54 Mbps PHY rate),
but depends on the channel width and MCS.

> Analyzing the Block Ack protocol, I think the BA bitmap only
> requires the Sequence Number (from the unencrypted MAC header) and
> CRC validation (PHY-level). So neither could require decryption keys.
> Could we allow this behavior?
> Is there a firmware mode where firmware acknowledges all CRC-valid
> frames in the BA regardless of decryption status?

I'd have said it should already work that way.

johannes