From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: johannes@sipsolutions.net
Cc: davem@davemloft.net, emmanuel.grumbach@intel.com,
herbert@gondor.apana.org.au, ilan.peer@intel.com,
jtornosm@redhat.com, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
miriam.rachel.korenblit@intel.com
Subject: Re: [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi
Date: Mon, 5 Oct 2026 18:45:21 +0200 [thread overview]
Message-ID: <20261005164521.1037345-1-jtornosm@redhat.com> (raw)
In-Reply-To: <4ede9873924541b7bed3fc09f5b8c8eb0415ea40.camel@sipsolutions.net>
Hi Johannes,
Following your guidance, I have been working on the v3 approach:
PTK/GTK software-only. Let me share my results, although spoiler,
I think I need a bit more of guidance.
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.
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.
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.
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?
That would allow RX aggregation with SW-only crypto and recover most of
the throughput.
The minimal diff on top of the fips_allows() infrastructure:
(only applying 1/5 and 5/5 patches)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -462,7 +462,7 @@
- if (!fips_enabled)
+ if (fips_allows(FIPS_EXCEPTION_WIFI_MFP))
ieee80211_hw_set(hw, MFP_CAPABLE);
@@ -1041,7 +1041,8 @@
- if (!iwl_enable_rx_ampdu()) {
+ if (!iwl_enable_rx_ampdu() ||
+ (fips_enabled && fips_allows(FIPS_EXCEPTION_WIFI_MFP))) {
ret = -EINVAL;
The first change restores MFP_CAPABLE when the FIPS exception is
set, so WPA3-SAE association works. The second change rejects
AddBA RX requests in FIPS mode, forcing individual PHY-level ACKs.
Thank you for your help
Best regards
Jose Ignacio
next prev parent reply other threads:[~2026-10-05 16:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 12:08 Jose Ignacio Tornos Martinez
2026-09-30 12:08 ` [PATCH v2 1/5] crypto: fips: add fips_exception kernel boot parameter and fips_allows() helper Jose Ignacio Tornos Martinez
2026-09-30 12:08 ` [PATCH v2 2/5] wifi: mac80211: allow keys to driver with fips_exception Jose Ignacio Tornos Martinez
2026-09-30 12:08 ` [PATCH v2 3/5] wifi: iwlwifi: restore FIPS-disabled features " Jose Ignacio Tornos Martinez
2026-09-30 12:08 ` [PATCH v2 4/5] wifi: iwlwifi: use software crypto for management frames in FIPS exception mode Jose Ignacio Tornos Martinez
2026-09-30 12:08 ` [PATCH v2 5/5] wifi: iwlwifi: reduce encryption error message to debug level in FIPS mode Jose Ignacio Tornos Martinez
2026-10-01 7:37 ` [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi Johannes Berg
2026-10-01 13:08 ` Jose Ignacio Tornos Martinez
2026-10-01 14:06 ` Johannes Berg
2026-10-01 15:59 ` Jose Ignacio Tornos Martinez
2026-10-01 16:19 ` Johannes Berg
2026-10-01 18:52 ` Jose Ignacio Tornos Martinez
2026-10-01 20:22 ` Johannes Berg
2026-10-02 10:45 ` Jose Ignacio Tornos Martinez
2026-10-05 16:45 ` Jose Ignacio Tornos Martinez [this message]
2026-10-05 20:55 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261005164521.1037345-1-jtornosm@redhat.com \
--to=jtornosm@redhat.com \
--cc=davem@davemloft.net \
--cc=emmanuel.grumbach@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=ilan.peer@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®