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

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

[Jose Ignacio Tornos Martinez]

Commits 5241526dede9 ("wifi: mac80211: don't send keys to driver when
fips_enabled") and 0636800c8ee1 ("wifi: iwlwifi: disable certain features
for fips_enabled") disabled WiFi functionality under FIPS mode because
Intel firmware autonomously sends some management frames without
FIPS-validated integrity protection.

While this is technically correct, it leaves FIPS-required environments
with no WiFi connectivity at all, since WPA3-SAE mandates MFP and without
MFP_CAPABLE the client cannot even associate.

The data encryption paths (CCMP/GCMP via PTK/GTK) are handled by mac80211
software crypto using FIPS-approved algorithms on the host CPU. The known
gap was management frame integrity protection on the TX side, where
firmware bypasses the host crypto stack.

This series introduces an opt-in fips_exception=<bitmap> kernel boot
parameter and an exported fips_allows() helper function that allows
administrators who understand the firmware limitation to explicitly
choose connectivity over strict compliance. The FIPS_EXCEPTION flag uses
generic WIFI_MFP naming (not iwlwifi-specific) since the mac80211 key
blocking affects all drivers. The default behavior remains exactly as the
original commits implemented.

v1 (2 patches) unconditionally re-enabled MFP without addressing
the firmware limitation for robust action frames and was rejected.
v2 replaces this with an opt-in exception, extends coverage to all
disabled features (key delivery, Beacon Protection, EHT, 6GHz,
A-MSDU, MLO) and both driver paths (mvm + mld), and adds SW_MGMT_TX
for host-side management frame protection.

AddBA (TX aggregation setup) cannot be fixed this way because firmware
creates these frames autonomously (TX_AMPDU_SETUP_IN_HW), bypassing
mac80211's TX path. The only observed degradation with the exception
active is reduced uplink throughput: firmware-created AddBA requests
are silently discarded by the AP, so TX aggregation is not established.
Downlink aggregation (AP to STA) works normally. No other functionality
is observed to be affected. Since the AP drops unprotected
firmware-autonomous frames rather than accepting them, the system
remains secure — those frames are simply not considered.

Multicast robust management frames (e.g. group-addressed deauth in AP
mode) are protected by IGTK via AES-CMAC/GMAC, which mac80211 handles in
software. Firmware-generated multicast management frames may lack
integrity protection, but a STA does not generate these normally.

Spectrum Management / CSA: a STA does not send CSA (AP-only).
On the RX/STA side, re-enabling MFP and Beacon Protection
(patches 2/3) restores the existing mac80211 protection layers:
1. MFP (patch 3) drops unprotected Spectrum Management action
   frames — these are robust action frames (category 0)
2. Beacon Protection (patch 3) validates beacon CSA IEs via BIGTK
3. Unprotectable Extended CSA (Public action, category 4) only
   blocks TX queues and requires beacon confirmation before channel
   switch (ieee80211_sta_process_chanswitch)
Spectrum Management responses from the STA (e.g. Measurement
Report) are built by mac80211, not firmware, so they go through
the normal TX path and are protected by SW_MGMT_TX (patch 4).
On the TX/AP side, beacons are built from mac80211 template and
protected by Beacon Protection (BIGTK) when re-enabled.

WoWLAN remains disabled under FIPS regardless of the exception flag,
as it requires all traffic to be handled by firmware crypto during
suspend (the host CPU is not available for mac80211 software crypto).

Patch details:
Patch 1: Adds the fips_exception infrastructure (boot parameter,
         read-only sysctl, fips_allows() helper)
Patch 2: Gates the mac80211 key blocking with fips_allows() so keys
         can reach the firmware for data traffic
Patch 3: Gates the iwlwifi feature disabling with fips_allows(),
         restoring MFP, Beacon Protection, EHT, 6GHz, A-MSDU sizes
         and MLO support
Patch 4: Best effort to force software encryption for unicast
         management frames (CCMP/GCMP). It sets
         IEEE80211_KEY_FLAG_SW_MGMT_TX on pairwise CCMP/GCMP keys when the
         exception is active, forcing mac80211 to encrypt unicast robust
         management frames (SA Query, deauth, disassoc) in software using
         FIPS-approved CCMP/GCMP, the same mechanism used by ath9k, ath5k,
         carl9170, mt76x02, rtw88, rtw89, rtlwifi, ... and other drivers.
Patch 5: Reduces firmware decryption error message to debug level in
         FIPS mode. Same as v1 patch 2/2, accepted upstream but not
         yet landed.

Tested on Intel WiFi 6E AX210 with fips=1 fips_exception=0x1:
- WPA3-SAE connection with MFP required succeeds
- iw station dump confirms "MFP: yes"
- Data traffic (TX/RX) works normally

v2: complete, improve and justify
    consider and analyze the feedback from Johannes Berg
v1: https://lore.kernel.org/all/20260629121213.597038-1-jtornosm@redhat.com/

Jose Ignacio Tornos Martinez (5):
  crypto: fips: add fips_exception kernel boot parameter and
    fips_allows() helper
  wifi: mac80211: allow keys to driver with fips_exception
  wifi: iwlwifi: restore FIPS-disabled features with fips_exception
  wifi: iwlwifi: use software crypto for management frames in FIPS
    exception mode
  wifi: iwlwifi: reduce encryption error message to debug level in FIPS
    mode

-- 
2.55.0

[PATCH v2 1/5] crypto: fips: add fips_exception kernel boot parameter and fips_allows() helper

[Jose Ignacio Tornos Martinez]

Add a new kernel boot parameter fips_exception=<bitmap> to allow
documented exceptions to strict FIPS compliance when full compliance
is not achievable due to hardware/firmware limitations but
functionality is required.

The parameter is stored in a static variable and accessed through the
exported fips_allows() helper function, which returns true if FIPS is
not enabled or the requested exception bit is set. It is not meant
for fully FIPS-compliant features.

For !CONFIG_CRYPTO_FIPS, fips_allows() is a trivial static inline
returning true.

The parameter is exposed as a read-only sysctl at
/proc/sys/crypto/fips_exception for runtime inspection. As with
fips_enabled, it is intentionally not writable at runtime so that
enabling exceptions requires a deliberate boot-time decision,
visible in /proc/cmdline.

The bitmap design allows individual subsystem exceptions to be
defined independently. Currently defined bits:
  - Bit 0 (FIPS_EXCEPTION_WIFI_MFP): Allow WiFi MFP (802.11w)
    in FIPS mode despite firmware sending some unprotected
    management frames on TX

Without this parameter (or with fips_exception=0), all existing
FIPS restrictions remain in effect.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: new, add crypto exception for fips
v1: https://lore.kernel.org/all/20260629121213.597038-1-jtornosm@redhat.com/

 crypto/fips.c        | 27 +++++++++++++++++++++++++++
 include/linux/fips.h | 14 ++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/crypto/fips.c b/crypto/fips.c
index c59711248d95..0f075e61a657 100644
--- a/crypto/fips.c
+++ b/crypto/fips.c
@@ -21,6 +21,15 @@ EXPORT_SYMBOL_GPL(fips_enabled);
 ATOMIC_NOTIFIER_HEAD(fips_fail_notif_chain);
 EXPORT_SYMBOL_GPL(fips_fail_notif_chain);
 
+static unsigned long fips_exception;
+
+int fips_allows(unsigned long feature)
+{
+	return !fips_enabled ||
+	       (fips_exception & feature);
+}
+EXPORT_SYMBOL_GPL(fips_allows);
+
 /* Process kernel command-line parameter at boot time. fips=0 or fips=1 */
 static int __init fips_enable(char *str)
 {
@@ -34,6 +43,17 @@ static int __init fips_enable(char *str)
 
 __setup("fips=", fips_enable);
 
+static int __init fips_exception_setup(char *str)
+{
+	if (kstrtoul(str, 0, &fips_exception))
+		return 0;
+
+	pr_info("fips exceptions: 0x%lx\n", fips_exception);
+	return 1;
+}
+
+__setup("fips_exception=", fips_exception_setup);
+
 #define FIPS_MODULE_NAME CONFIG_CRYPTO_FIPS_NAME
 #ifdef CONFIG_CRYPTO_FIPS_CUSTOM_VERSION
 #define FIPS_MODULE_VERSION CONFIG_CRYPTO_FIPS_VERSION
@@ -52,6 +72,13 @@ static const struct ctl_table crypto_sysctl_table[] = {
 		.mode		= 0444,
 		.proc_handler	= proc_dointvec
 	},
+	{
+		.procname	= "fips_exception",
+		.data		= &fips_exception,
+		.maxlen		= sizeof(unsigned long),
+		.mode		= 0444,
+		.proc_handler	= proc_doulongvec_minmax
+	},
 	{
 		.procname	= "fips_name",
 		.data		= &fips_name,
diff --git a/include/linux/fips.h b/include/linux/fips.h
index c6961e932fef..61fe58b0762c 100644
--- a/include/linux/fips.h
+++ b/include/linux/fips.h
@@ -2,17 +2,31 @@
 #ifndef _FIPS_H
 #define _FIPS_H
 
+#include <linux/bits.h>
+
 #ifdef CONFIG_CRYPTO_FIPS
 extern int fips_enabled;
 extern struct atomic_notifier_head fips_fail_notif_chain;
 
 void fips_fail_notify(void);
+/*
+ * fips_allows - check if a not fully FIPS-compliant feature is allowed
+ * via an explicit boot-time exception (fips_exception=).
+ * Not for fully FIPS-compliant features.
+ */
+int fips_allows(unsigned long feature);
 
 #else
 #define fips_enabled 0
 
 static inline void fips_fail_notify(void) {}
+static inline int fips_allows(unsigned long feature)
+{
+	return 1;
+}
 
 #endif
 
+#define FIPS_EXCEPTION_WIFI_MFP	BIT(0)
+
 #endif
-- 
2.55.0

[PATCH v2 2/5] wifi: mac80211: allow keys to driver with fips_exception

[Jose Ignacio Tornos Martinez]

Commit 5241526dede9 ("wifi: mac80211: don't send keys to driver
when fips_enabled") blocks all keys from reaching the firmware
when fips_enabled. While this prevents firmware from using
non-validated crypto, it also means the firmware has no PTK/GTK
installed and blocks all data frames, resulting in a WiFi
connection authorized but with no traffic.

When FIPS_EXCEPTION_WIFI_MFP is set via fips_exception boot
parameter, use fips_allows() to allow keys to reach the firmware
so that data traffic works. The data encryption (CCMP/GCMP) is
still handled by mac80211 software crypto using FIPS-approved
algorithms on the host CPU, but the firmware needs the keys
installed to allow frames through.

Without fips_exception set, the behavior remains exactly as
commit 5241526dede9 implemented.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: complete the conditional FIPS disabling revert
v1: https://lore.kernel.org/all/20260629121213.597038-2-jtornosm@redhat.com/

 net/mac80211/driver-ops.c | 2 +-
 net/mac80211/driver-ops.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index 49753b73aba2..0a50684d9cf6 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -519,7 +519,7 @@ int drv_set_key(struct ieee80211_local *local,
 		    !(sdata->vif.active_links & BIT(key->link_id))))
 		return -ENOLINK;
 
-	if (fips_enabled)
+	if (!fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 		return -EOPNOTSUPP;
 
 	trace_drv_set_key(local, cmd, sdata, sta, key);
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index f1c0b87fddd5..a24230feb864 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -903,7 +903,7 @@ static inline void drv_set_rekey_data(struct ieee80211_local *local,
 	if (!check_sdata_in_driver(sdata))
 		return;
 
-	if (fips_enabled)
+	if (!fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 		return;
 
 	trace_drv_set_rekey_data(local, sdata, data);
-- 
2.55.0

[PATCH v2 3/5] wifi: iwlwifi: restore FIPS-disabled features with fips_exception

[Jose Ignacio Tornos Martinez]

Commit 0636800c8ee1 ("wifi: iwlwifi: disable certain features
for fips_enabled") disabled multiple WiFi features under FIPS
mode because Intel firmware autonomously sends some management
frames without FIPS-validated integrity protection. This is
correct from a compliance standpoint but breaks WiFi connectivity
entirely on WPA3-SAE networks which mandate MFP.

When FIPS_EXCEPTION_WIFI_MFP is set via fips_exception boot
parameter, use fips_allows() to restore the following features
disabled by that commit:

In the mvm driver path (mvm/mac80211.c):
  - MFP_CAPABLE: required for WPA3-SAE association
  - Beacon Protection (full and client-only): integrity
    protection for beacons, handled by firmware

In the mld driver path (mld/mac80211.c):
  - Cipher suites and MFP_CAPABLE: required for WPA3-SAE
  - Beacon Protection: same as mvm path
  - MLO (Multi-Link Operation): disabled because it requires MFP

In iwl-nvm-parse.c (shared by both paths):
  - A-MSDU max sizes: reduced under FIPS, restored with exception
  - EHT/WiFi7 capabilities: disabled because EHT requires MFP
  - 6GHz channels: disabled because 6GHz requires WPA3/MFP

A warning is logged for both mvm and mld drivers when the
exception is active to ensure the known firmware limitation
is visible:
  "FIPS: MFP enabled with known firmware limitation"

WoWLAN remains disabled under FIPS regardless of the exception
flag in both mvm and mld paths. Unlike MFP where only some
management frames bypass host crypto, WoWLAN requires all
traffic to be handled by firmware crypto during suspend, as
the host CPU is not available for mac80211 software crypto.

Without fips_exception set, the behavior remains exactly as
commit 0636800c8ee1 implemented.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: complete the conditional FIPS disabling revert
v1: https://lore.kernel.org/all/20260629121213.597038-2-jtornosm@redhat.com/

 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 11 +++++++----
 drivers/net/wireless/intel/iwlwifi/mld/mac80211.c  |  7 +++++--
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  9 ++++++---
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index 863d5e358152..ca565b4311bb 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -502,14 +502,16 @@ static void iwl_init_vht_hw_capab(struct iwl_trans *trans,
 	 */
 	switch (iwlwifi_mod_params.amsdu_size) {
 	case IWL_AMSDU_DEF:
-		if (trans->mac_cfg->mq_rx_supported && !fips_enabled)
+		if (trans->mac_cfg->mq_rx_supported &&
+		    fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 			vht_cap->cap |=
 				IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454;
 		else
 			vht_cap->cap |= IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895;
 		break;
 	case IWL_AMSDU_2K:
-		if (trans->mac_cfg->mq_rx_supported && !fips_enabled)
+		if (trans->mac_cfg->mq_rx_supported &&
+		    fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 			vht_cap->cap |=
 				IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454;
 		else
@@ -886,7 +888,7 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
 
 	/* EHT needs WPA3/MFP so cannot do it for fips_enabled */
 	if (!data->sku_cap_11be_enable || iwlwifi_mod_params.disable_11be ||
-	    fips_enabled)
+	    !fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 		iftype_data->eht_cap.has_eht = false;
 
 	if (!data->sku_cap_11bn_enable || !iftype_data->eht_cap.has_eht)
@@ -1221,7 +1223,8 @@ static void iwl_init_sbands(struct iwl_trans *trans,
 	 * avoid spending time on scanning those channels and perhaps
 	 * even finding APs there that cannot be used.
 	 */
-	if (!fips_enabled && data->sku_cap_11ax_enable &&
+	if (fips_allows(FIPS_EXCEPTION_WIFI_MFP) &&
+	    data->sku_cap_11ax_enable &&
 	    !iwlwifi_mod_params.disable_11ax)
 		iwl_init_he_hw_capab(trans, data, sband, tx_chains, rx_chains,
 				     fw);
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 3a4c8fda68d0..3ccbf1033160 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -167,7 +167,7 @@ static void iwl_mld_hw_set_security(struct iwl_mld *mld)
 		WLAN_CIPHER_SUITE_BIP_GMAC_256
 	};
 
-	if (fips_enabled)
+	if (!fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 		return;
 
 	hw->wiphy->n_cipher_suites = ARRAY_SIZE(mld_ciphers);
@@ -176,6 +176,9 @@ static void iwl_mld_hw_set_security(struct iwl_mld *mld)
 	ieee80211_hw_set(hw, MFP_CAPABLE);
 	wiphy_ext_feature_set(hw->wiphy,
 			      NL80211_EXT_FEATURE_BEACON_PROTECTION);
+
+	if (fips_enabled)
+		IWL_WARN(mld, "FIPS: MFP enabled with known firmware limitation\n");
 }
 
 static void iwl_mld_hw_set_antennas(struct iwl_mld *mld)
@@ -344,7 +347,7 @@ static void iwl_mac_hw_set_wiphy(struct iwl_mld *mld)
 	if (mld->nvm_data->sku_cap_11be_enable &&
 	    !iwlwifi_mod_params.disable_11ax &&
 	    !iwlwifi_mod_params.disable_11be &&
-	    !fips_enabled)
+	    fips_allows(FIPS_EXCEPTION_WIFI_MFP))
 		wiphy->flags |= WIPHY_FLAG_SUPPORTS_MLO;
 
 	/* the firmware uses u8 for num of iterations, but 0xff is saved for
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 5bd246e37943..f6e20a07e329 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -462,8 +462,11 @@ 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)
+	if (fips_allows(FIPS_EXCEPTION_WIFI_MFP)) {
 		ieee80211_hw_set(hw, MFP_CAPABLE);
+		if (fips_enabled)
+			IWL_WARN(mvm, "FIPS: MFP enabled with known firmware limitation\n");
+	}
 
 	mvm->ciphers[hw->wiphy->n_cipher_suites] = WLAN_CIPHER_SUITE_AES_CMAC;
 	hw->wiphy->n_cipher_suites++;
@@ -492,12 +495,12 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
 	 * beacon protection must be handled by firmware,
 	 * so cannot be done with fips_enabled
 	 */
-	if (!fips_enabled && sec_key_ver &&
+	if (fips_allows(FIPS_EXCEPTION_WIFI_MFP) && sec_key_ver &&
 	    fw_has_capa(&mvm->fw->ucode_capa,
 			IWL_UCODE_TLV_CAPA_BIGTK_TX_SUPPORT))
 		wiphy_ext_feature_set(hw->wiphy,
 				      NL80211_EXT_FEATURE_BEACON_PROTECTION);
-	else if (!fips_enabled &&
+	else if (fips_allows(FIPS_EXCEPTION_WIFI_MFP) &&
 		 fw_has_capa(&mvm->fw->ucode_capa,
 			     IWL_UCODE_TLV_CAPA_BIGTK_SUPPORT))
 		wiphy_ext_feature_set(hw->wiphy,
-- 
2.55.0

[PATCH v2 4/5] wifi: iwlwifi: use software crypto for management frames in FIPS exception mode

[Jose Ignacio Tornos Martinez]

Best effort to protect as many outgoing robust management frames
as possible via host-side software crypto, given the firmware
limitations.

When the FIPS exception is active and keys are delivered to
firmware, mac80211 delegates management frame encryption to
firmware via hw_key. However, Intel firmware does not properly
apply CCMP/GCMP integrity protection to these frames, causing
the AP to drop them when MFP is negotiated.

Set IEEE80211_KEY_FLAG_SW_MGMT_TX on pairwise CCMP/GCMP keys
when fips_enabled, so that mac80211 encrypts unicast management
frames in software using FIPS-approved algorithms on the host
CPU. This is the same mechanism used by ath9k, ath5k, carl9170,
mt76x02, rtw88, rtw89, rtlwifi, ... and other drivers whose
firmware cannot encrypt management frames.

This protects SA Query, deauth, disassoc and other unicast
robust management frames built by mac80211. Multicast robust
management frames (IGTK/AES-CMAC/GMAC) are already handled
in software by mac80211, so no additional flag is needed.

AddBA (TX aggregation setup) cannot be fixed this way because
firmware creates these frames autonomously when
TX_AMPDU_SETUP_IN_HW is set, bypassing mac80211's TX path
entirely. Fixing this would require firmware-side changes.

The only observed degradation with the exception active is
reduced uplink throughput: firmware-created AddBA requests are
sent without integrity protection and silently discarded by
the AP, so TX aggregation is not established. Downlink
aggregation (AP to STA) works normally. No other functionality
is observed to be affected. Since the AP drops unprotected
firmware-autonomous frames rather than accepting them, the
system remains secure — those frames are simply not considered.

When set_key is reached with fips_enabled, the exception must
be active (otherwise drv_set_key blocks keys), so checking
fips_enabled alone is sufficient.

Both mvm and mld driver paths are covered.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: new, to improve the behavior
v1: https://lore.kernel.org/all/20260629121213.597038-1-jtornosm@redhat.com/

 drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 3 +++
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 3ccbf1033160..3fd88420cd17 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -2230,6 +2230,9 @@ static int iwl_mld_set_key_add(struct iwl_mld *mld,
 	case WLAN_CIPHER_SUITE_CCMP:
 	case WLAN_CIPHER_SUITE_GCMP:
 	case WLAN_CIPHER_SUITE_GCMP_256:
+		if (fips_enabled && (key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+			key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
+		break;
 	case WLAN_CIPHER_SUITE_AES_CMAC:
 	case WLAN_CIPHER_SUITE_BIP_GMAC_128:
 	case WLAN_CIPHER_SUITE_BIP_GMAC_256:
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index f6e20a07e329..38fe710ef414 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -4247,6 +4247,8 @@ static int __iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
 	case WLAN_CIPHER_SUITE_GCMP_256:
 		if (!iwl_mvm_has_new_tx_api(mvm))
 			key->flags |= IEEE80211_KEY_FLAG_PUT_IV_SPACE;
+		if (fips_enabled && (key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+			key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
 		break;
 	case WLAN_CIPHER_SUITE_AES_CMAC:
 	case WLAN_CIPHER_SUITE_BIP_GMAC_128:
-- 
2.55.0

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

[Jose Ignacio Tornos Martinez]

In FIPS mode, the firmware may report
RX_MPDU_RES_STATUS_SEC_ENC_ERR (0x707) for frames received
before keys are installed. This triggers the warning:
  "iwlwifi: Unhandled alg: 0x707"

This is expected behavior — mac80211 software crypto handles
decryption on the host CPU. Reduce the message from IWL_WARN to
IWL_DEBUG_RX in FIPS mode to avoid false-positive warnings
during normal operation, while preserving warnings for actual
unexpected conditions.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: No modification
v1: https://lore.kernel.org/all/20260629121213.597038-3-jtornosm@redhat.com/ 

 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 7f0b4f5daa21..6d223ef75bb4 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,14 @@ 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) {
+			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.55.0

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

[Johannes Berg]

Hi Jose,

I'm super confused by this, it looks like mostly random code changes to
not really do anything useful any more ... Nor do the code changes seem
to actually be doing what you describe.

> Commits 5241526dede9 ("wifi: mac80211: don't send keys to driver when
> fips_enabled") and 0636800c8ee1 ("wifi: iwlwifi: disable certain features
> for fips_enabled") disabled WiFi functionality under FIPS mode because
> Intel firmware autonomously sends some management frames without
> FIPS-validated integrity protection.
> 
> While this is technically correct, it leaves FIPS-required environments
> with no WiFi connectivity at all, since WPA3-SAE mandates MFP and without
> MFP_CAPABLE the client cannot even associate.

Arguably, that's what FIPS wanted. It mandates that you cannot give keys
to the device since it's not certified, and therefore it cannot do the
necessary functionality for these connections.

I can understand why you don't like it, and I guess we can try to find
ways around it like what you fundamentally seem to try to be doing here,
i.e. formulate an exception to the policies.

But I think you should actually formulate the exception that you *want*
first and then implement it, not randomly poke holes into the code and
call it done.

> Patch 1: Adds the fips_exception infrastructure (boot parameter,
>          read-only sysctl, fips_allows() helper)

Not my domain, but I'd argue that design documentation I ask for above
should somehow make it into the documentation for this parameter so taht
administrators can actually make an informed decision.

> Patch 2: Gates the mac80211 key blocking with fips_allows() so keys
>          can reach the firmware for data traffic

This patch is mostly wrong. If the exception is called "MFP" then
there's no need to pass all keys, and in fact the way you implemented
it, I don't even see how it doesn't end up with HW crypto after all.

> Patch 3: Gates the iwlwifi feature disabling with fips_allows(),
>          restoring MFP, Beacon Protection, EHT, 6GHz, A-MSDU sizes
>          and MLO support

This is also partially wrong - you didn't really understand this and
just undid everything?

> Patch 4: Best effort to force software encryption for unicast
>          management frames (CCMP/GCMP). It sets
>          IEEE80211_KEY_FLAG_SW_MGMT_TX on pairwise CCMP/GCMP keys when the
>          exception is active, forcing mac80211 to encrypt unicast robust
>          management frames (SA Query, deauth, disassoc) in software using
>          FIPS-approved CCMP/GCMP, the same mechanism used by ath9k, ath5k,
>          carl9170, mt76x02, rtw88, rtw89, rtlwifi, ... and other drivers.

This makes no sense at all.

> Patch 5: Reduces firmware decryption error message to debug level in
>          FIPS mode. Same as v1 patch 2/2, accepted upstream but not
>          yet landed.

That seems reasonable.

I'm not going to reply to the individual patches, but I observe that you
didn't understand IGTK functionality, WoWLAN, A-MSDUs, or maybe
encryption offload in general. From what I can tell, your patches are
mostly equivalent to turning FIPS off for wifi.

I don't know where to go from here. I don't think I'm going to teach you
all the necessary things here in the context of an upstream review, or
redo the patches correctly myself. Maybe you can approach Intel over the
distro channel Redhat has and ask them to help. Which will almost
certainly end up falling back to me, but at least then we can support it
and it's accounted for.

johannes