[PATCH 0/2] wifi: iwlwifi: Fix WiFi operation in FIPS mode

[PATCH 0/2] wifi: iwlwifi: Fix WiFi operation in FIPS mode

[Jose Ignacio Tornos Martinez]

This series re-enables WiFi connectivity in FIPS mode for iwlwifi by
allowing Management Frame Protection (MFP/802.11w) to work with mac80211
software crypto.

Currently, iwlwifi connections fail in FIPS mode because commit
0636800c8ee1 (("wifi: iwlwifi: disable certain features for fips_enabled")
disabled MFP_CAPABLE when fips_enabled=1. The testing shows that MFP works
correctly in FIPS mode when mac80211 software crypto handles IGTK encryption
/decryption using FIPS-approved AES-CMAC/GMAC algorithms.

I think the original concern that "MFP since some frames need to be handled
in firmware" can be avoided for normal STA operation. The firmware-offload
requirement appears to apply specifically to features like WoWLAN and beacon
protection, which remain correctly disabled. AFAIK, for standard client
connections, management frames are processed only in software and mac80211
provides complete IGTK handling.

Patch 1 re-enables MFP_CAPABLE for iwlwifi to allow basic WiFi client
operation in FIPS mode. Patch 2 reduces a misleading warning message that
appears during normal FIPS operation to debug level - the warning actually
confirms that frames are not processed by firmware and are correctly handled
by software crypto instead.

Testing on Intel WiFi 6E AX210 with fips=1:

Before:
  # cat /proc/sys/crypto/fips_enabled
  1
  # iw phy phy0 info | grep -A 10 "Cipher"
  Supported Ciphers:
      * CCMP-128 (00-0f-ac:4)
      * CCMP-256 (00-0f-ac:10)
      * GCMP-128 (00-0f-ac:8)
      * GCMP-256 (00-0f-ac:9)
  # nmcli connection up SSID
  Error: Connection activation failed

After:
  # cat /proc/sys/crypto/fips_enabled
  1
  # iw phy phy0 info | grep -A 10 "Cipher"
  Supported Ciphers:
      * CCMP-128 (00-0f-ac:4)
      * CCMP-256 (00-0f-ac:10)
      * GCMP-128 (00-0f-ac:8)
      * GCMP-256 (00-0f-ac:9)
      * CMAC (00-0f-ac:6)
      * CMAC-256 (00-0f-ac:13)
      * GMAC-128 (00-0f-ac:11)
      * GMAC-256 (00-0f-ac:12)
  # nmcli connection up SSID
  Connection successfully activated
  # iw dev wlp7s0 station dump | grep MFP
  MFP:        yes

Jose Ignacio Tornos Martinez (2):
  wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode
  wifi: iwlwifi: reduce encryption error message to debug level in FIPS mode

--
2.47.1

[PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Jose Ignacio Tornos Martinez]

Re-enable MFP_CAPABLE flag in FIPS mode for iwlwifi to allow Management
Frame Protection (802.11w) to work with mac80211 software crypto.

Commit 0636800c8ee1 ("wifi: iwlwifi: disable certain features for
fips_enabled") disabled MFP_CAPABLE when fips_enabled=1.
I think the original concern about "some frames need to be handled in
firmware" applies to firmware-offloaded features like WoWLAN and beacon
protection, which remain correctly disabled by the commented commit.
For normal STA mode operation, management frames are processed in software.
And MFP can function in FIPS mode for normal STA operation when mac80211
software crypto handles IGTK encryption/decryption using FIPS-approved
AES-CMAC/GMAC algorithms.

Other major WiFi drivers (ath11k, rtlwifi, mt76, ...) set MFP_CAPABLE
unconditionally, suggesting this approach is viable for FIPS mode operation
with software crypto.

After re-enabling, testing on Intel WiFi 6E AX210 with fips=1 shows:
- IGTK ciphers (CMAC, GMAC-128, GMAC-256) are properly advertised
- WPA3-SAE connections with MFP required succeed
- iw station dump confirms "MFP: yes"

Firmware logs "Unhandled alg: 0x707" (SEC_ENC_ERR) during operation,
confirming that firmware does not have the keys and frames are being
handled by software crypto as expected.

Fixes: 0636800c8ee1 ("wifi: iwlwifi: disable certain features for fips_enabled")
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 1ec9807e4827..b0aea73c5784 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -462,8 +462,7 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
 		IWL_ERR(mvm,
 			"iwlmvm doesn't allow to disable BT Coex, check bt_coex_active module parameter\n");
 
-	if (!fips_enabled)
-		ieee80211_hw_set(hw, MFP_CAPABLE);
+	ieee80211_hw_set(hw, MFP_CAPABLE);
 
 	mvm->ciphers[hw->wiphy->n_cipher_suites] = WLAN_CIPHER_SUITE_AES_CMAC;
 	hw->wiphy->n_cipher_suites++;
-- 
2.54.0

[PATCH 2/2] wifi: iwlwifi: reduce encryption error message to debug level in FIPS mode

[Jose Ignacio Tornos Martinez]

Reduce and modify in FIPS mode the warning message:
  "iwlwifi 0000:07:00.0: Unhandled alg: 0x707"
from IWL_WARN to IWL_DEBUG_RX when fips_enabled is true and status is
RX_MPDU_RES_STATUS_SEC_ENC_ERR (0x707), as this is expected behavior
in FIPS mode and not an error.

The current IWL_WARN message misleadingly suggests an error when this
is actually the intended behavior - firmware crypto disabled, software
crypto handling MFP frames using FIPS-approved AES-CMAC/GMAC algorithms.

These messages appear infrequently (shortly after association when first
IGTK-protected frames arrive) and are already rate-limited, so reducing
them to debug level in FIPS mode removes the false impression of a
problem while still providing useful information for debugging.

This prevents false-positive "Unhandled alg" warnings from appearing
in normal FIPS mode operation with Management Frame Protection enabled,
while preserving warnings for actual unexpected conditions.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 7f0b4f5daa21..3d6760d5c500 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -6,6 +6,7 @@
  */
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
+#include <linux/fips.h>
 #include "iwl-trans.h"
 #include "mvm.h"
 #include "fw-api.h"
@@ -494,6 +495,16 @@ static int iwl_mvm_rx_crypto(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
 		return 0;
 	case RX_MPDU_RES_STATUS_SEC_CMAC_GMAC_ENC:
 		break;
+	case RX_MPDU_RES_STATUS_SEC_ENC_ERR:
+		if (fips_enabled) {
+			/* Expected in FIPS mode - firmware has no keys,
+			 * mac80211 software crypto will handle it
+			 */
+			IWL_DEBUG_RX(mvm, "FIPS mode: Firmware cannot decrypt, status: 0x%x\n",
+				     status);
+			break;
+		}
+		fallthrough;
 	default:
 		/*
 		 * Sometimes we can get frames that were not decrypted
-- 
2.54.0

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Johannes Berg]

On Mon, 2026-06-29 at 14:12 +0200, Jose Ignacio Tornos Martinez wrote:
> Re-enable MFP_CAPABLE flag in FIPS mode for iwlwifi to allow Management
> Frame Protection (802.11w) to work with mac80211 software crypto.
> 
> Commit 0636800c8ee1 ("wifi: iwlwifi: disable certain features for
> fips_enabled") disabled MFP_CAPABLE when fips_enabled=1.
> I think the original concern about "some frames need to be handled in
> firmware" applies to firmware-offloaded features like WoWLAN and beacon
> protection, which remain correctly disabled by the commented commit.

No, you think wrong, this cannot be done.

johannes

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Jose Ignacio Tornos Martinez]

Hi Johannes,

Thank you for the quick response. 

Since we have some customers requesting this, I'd appreciate some
clarification on what specifically cannot be done so I can better
understand the firmware requirements.

Our testing shows MFP working with software crypto in FIPS mode
(connection succeeds, "MFP: yes" confirmed, firmware reports SEC_ENC_ERR
0x707 indicating it's not handling the frames). Indeed it was working like
this before your commit.
But clearly I'm missing  something important about the architecture.

Could you help me to understand:
- What breaks when MFP_CAPABLE is enabled in FIPS mode?
- Is there a specific scenario (beyond WoWLAN/beacon protection) where
  firmware must handle MFP frames?
- Is the issue that it appears to work but fails in certain conditions?

If possible, I would like to get information at least to justify the
reasons why FIPS cannot be used with WiFi Intel cards (or if there is
some way/approach to make it work).

Thanks

Best regards
Jose Ignacio

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Johannes Berg]

Hi,

> Since we have some customers requesting this, I'd appreciate some
> clarification on what specifically cannot be done so I can better
> understand the firmware requirements.

The firmware handles various action frames that are robust action
frames, so their protection must be checked on RX and they must be
protected on TX. For example, CSA (spectrum management) action frames,
or Block-Ack action frames.

> Our testing shows MFP working with software crypto in FIPS mode
> (connection succeeds, "MFP: yes" confirmed, firmware reports SEC_ENC_ERR
> 0x707 indicating it's not handling the frames). Indeed it was working like
> this before your commit.

Sure, it *works*, but it's not secure nor fast.

> Could you help me to understand:
> - What breaks when MFP_CAPABLE is enabled in FIPS mode?
> - Is there a specific scenario (beyond WoWLAN/beacon protection) where
>   firmware must handle MFP frames?

See above, I think.

> - Is the issue that it appears to work but fails in certain conditions?
> 
> If possible, I would like to get information at least to justify the
> reasons why FIPS cannot be used with WiFi Intel cards (or if there is
> some way/approach to make it work).

I don't think there's any good/secure way of doing this.

johannes

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Jose Ignacio Tornos Martinez]

Hi Johannes,
  
Thank you for the detailed explanation about the firmware-handled robust
action frames (CSA, Block-Ack, etc.).

Now that I understand why MFP cannot work securely in FIPS mode on Intel
hardware, I'll drop the patches.

Thanks for your time

Best regards
José Ignacio

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Johannes Berg]

Hi,

> Now that I understand why MFP cannot work securely in FIPS mode on Intel
> hardware, I'll drop the patches.

There's probably something to be said for the second patch anyway.

Also, maybe we'd actually be interested in who's using this and why,
it's the first I hear of this outside of _very_ niche applications :)

johannes

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Jose Ignacio Tornos Martinez]

Hi Johannes,

> There's probably something to be said for the second patch anyway.
Good to know, should I resend patch 2/2 separately, or would you like me
to wait until I have the customer use case information?

> Also, maybe we'd actually be interested in who's using this and why,
> it's the first I hear of this outside of _very_ niche applications :)
I'm collecting that information from our support team now and I'll share
what I can once I have it.

Thanks

Best regards
José Ignacio

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Johannes Berg]

On Tue, 2026-06-30 at 09:20 +0200, Jose Ignacio Tornos Martinez wrote:
> Hi Johannes,
> 
> > There's probably something to be said for the second patch anyway.
> Good to know, should I resend patch 2/2 separately, or would you like me
> to wait until I have the customer use case information?

I think we can just take it as-is.

johannes

Re: [PATCH 1/2] wifi: iwlwifi: enable MFP_CAPABLE in FIPS mode

[Jose Ignacio Tornos Martinez]

Hi Johannes,

>>> There's probably something to be said for the second patch anyway.
>> Good to know, should I resend patch 2/2 separately, or would you like me
>> to wait until I have the customer use case information?
> I think we can just take it as-is.
Great, thank you!

I'll still get you the customer use case information once I have it.

Best regards
José Ignacio