[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

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

[Jose Ignacio Tornos Martinez]

Hi Johannes,

Based on the discussion around v1, I tried to prepare a more complete
proposal addressing the concerns raised there (AddBA, CSA, robust
action frames). I understand I may have gone too broad and missed
some aspects of how encryption offload works internally, without
access to firmware documentation it is difficult to get everything
right.

Just to clarify a few points, WoWLAN was intentionally kept disabled
in the patches (both mvm and mld paths), precisely because it requires
all traffic via firmware crypto during suspend. IGTK handling was not
changed either, as mac80211 already handles it in software. A-MSDUs
are not directly MFP-related, fair point, but they were part of the
same commit being reverted, because patch 2 and patch 3 are just
reverting some parts of the FIPS disabling to try to get it working
again under the exception.

On the specific patches:

Patch 2: In v1, I only re-enabled MFP_CAPABLE without passing keys
to firmware, the result was connection but no data traffic. That is
why I added key delivery in v2. Is it possible to keep software
crypto for data while having a functional connection, or does the
firmware require keys installed to pass frames? This would help me
understand the correct approach.

Patch 3: I can narrow this to the minimum needed. Some features
(EHT, 6GHz) depend on MFP so I included them, but I agree it
could be more selective.

Patch 4: The intent was host-side crypto for management frames via
SW_MGMT_TX (same mechanism as ath9k, rtw89, etc.), but I understand
this depends on how patch 2 is resolved.

Ultimately, I just want to fix a problem affecting our customers who
are interested in keeping WiFi working, accepting that some lower-level
management frames are not FIPS-compliant while the important part for
them, data encryption, is. The default behavior is maintained, this
is only allowed if the exception is explicitly configured. This was
working before the commits and our customers already have this
hardware deployed.

I don't want to bother you with more patches without guidance. I can
try to engage Intel on this, but any help, recommendation on the right
approach to try to solve this in some way would be appreciated.

Thanks

Best regards
Jose Ignacio

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

[Johannes Berg]

Hi Jose,

> Based on the discussion around v1, I tried to prepare a more complete
> proposal addressing the concerns raised there (AddBA, CSA, robust
> action frames). I understand I may have gone too broad and missed
> some aspects of how encryption offload works internally, without
> access to firmware documentation it is difficult to get everything
> right.

I don't think that's necessarily it.

> Just to clarify a few points, WoWLAN was intentionally kept disabled
> in the patches (both mvm and mld paths), precisely because it requires
> all traffic via firmware crypto during suspend.

Yes, it does remain disabled, but then (for example) why allow
set_rekey_offload() to go through - it's clearly not necessary.

> IGTK handling was not
> changed either, as mac80211 already handles it in software. A-MSDUs
> are not directly MFP-related, fair point, but they were part of the
> same commit being reverted, because patch 2 and patch 3 are just
> reverting some parts of the FIPS disabling to try to get it working
> again under the exception.

But again, what are you actually trying to achieve?

If you want big A-MSDUs, then you need hardware crypto, which you allow
now, which would seem to _completely_ defeat the purpose of FIPS here
(to protect data, if you read it charitably vs. just saying it's for
paper-pushing).

OTOH, why does IGTK matter so much to you? That particular key has no
relation to data protection, so arguably *that* could still be
offloaded. But you're doing it all precisely the other way around.

Hence - again - my request for you spelling out what you're actually
trying to achieve, rather than throwing random code at me.

> Patch 2: In v1, I only re-enabled MFP_CAPABLE without passing keys
> to firmware, the result was connection but no data traffic. That is
> why I added key delivery in v2. Is it possible to keep software
> crypto for data while having a functional connection, or does the
> firmware require keys installed to pass frames? This would help me
> understand the correct approach.

Well, it does work without MFP, so fundamentally the firmware can pass
data without having keys?

> Patch 3: I can narrow this to the minimum needed. Some features
> (EHT, 6GHz) depend on MFP so I included them, but I agree it
> could be more selective.

That's not the point - the point is that there are different
dependencies and you didn't think about _why_ something is disabled. Not
all of this is all related to MFP.

> Patch 4: The intent was host-side crypto for management frames via
> SW_MGMT_TX (same mechanism as ath9k, rtw89, etc.), but I understand
> this depends on how patch 2 is resolved.

But again, the way you did that doesn't make any sense.

> Ultimately, I just want to fix a problem affecting our customers who
> are interested in keeping WiFi working, accepting that some lower-level
> management frames are not FIPS-compliant while the important part for
> them, data encryption, is.

Which is the opposite of what you actually did.

> I don't want to bother you with more patches without guidance. I can
> try to engage Intel on this, but any help, recommendation on the right
> approach to try to solve this in some way would be appreciated.

I really do think it starts with spelling out what you (or your
customers) actually want, and what trade-offs wrt. FIPS you're willing
to accept.

johannes

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

[Jose Ignacio Tornos Martinez]

Hi Johannes,

> Yes, it does remain disabled, but then (for example) why allow
> set_rekey_offload() to go through - it's clearly not necessary.

Ok, understood, set_rekey_offload() is not needed with WoWLAN
disabled, that was an oversight.

> But again, what are you actually trying to achieve?

What I would like and what we need is: data encryption stays in
software (FIPS-compliant), WiFi connectivity works, and we accept
that some management frame protection is not fully FIPS-validated.

> If you want big A-MSDUs, then you need hardware crypto, which you allow
> now, which would seem to _completely_ defeat the purpose of FIPS here
> (to protect data, if you read it charitably vs. just saying it's for
> paper-pushing).

Analyzing it again with your comment, you are right about A-MSDUs,
if there is no HW crypto then big A-MSDUs are not possible anyway,
so restoring A-MSDU sizes was wrong.

> OTOH, why does IGTK matter so much to you? That particular key has no
> relation to data protection, so arguably *that* could still be
> offloaded. But you're doing it all precisely the other way around.

And you are right about IGTK, it has no relation to data protection
so it could be offloaded, and I should not have kept it in software
while sending PTK/GTK to firmware. That was indeed the opposite.

> Well, it does work without MFP, so fundamentally the firmware can pass
> data without having keys?

That is what I would expect, but in v1 I only re-enabled MFP_CAPABLE
without passing any keys to firmware and got connection but no data
traffic. Looking at the code, mac80211 SW crypto plumbing works
correctly when drv_set_key() does not install keys in hardware,
and the TX path sets IWL_TX_FLAGS_ENCRYPT_DIS for pre-encrypted
frames. So the host side should handle it. My suspicion is that
firmware changes its behavior when MFP is negotiated, expecting
keys to be installed, and drops encrypted data frames it cannot
decrypt instead of forwarding them to the host. The SEC_ENC_ERR
messages I saw in v1 were likely from management frames, not data.
Any guidance on this would help me take the right approach for v3.

> That's not the point - the point is that there are different
> dependencies and you didn't think about _why_ something is disabled.
> Not all of this is all related to MFP.

Fair point. These dependencies were not documented in the original
disabling commits, so I treated everything as a single block to
revert. Could you clarify which features depend on MFP, which on
HW crypto, and which on other reasons? That would help me get
the separation right.

> But again, the way you did that doesn't make any sense.

I just reverted the necessary parts (to me) to the previous working
state. I can narrow it once I understand the correct separation.

> Which is the opposite of what you actually did.

Understood. The patches gave data keys to firmware (defeating FIPS
for data) while keeping management keys in software. The correct
approach should be the reverse: keep PTK/GTK in software for
FIPS-compliant data encryption, and offload IGTK if needed since
it has no data relation. Happy to rework this properly for v3.

> I really do think it starts with spelling out what you (or your
> customers) actually want, and what trade-offs wrt. FIPS you're
> willing to accept.

Spelled out: data encryption (PTK/GTK) must stay in software
(FIPS-compliant). We accept that firmware-autonomous management
frames (like AddBA) are not FIPS-protected. We accept reduced
uplink throughput from missing TX aggregation. We do not need
big A-MSDUs or WoWLAN. The goal is a working WPA3-SAE connection
with FIPS-compliant data path.

Also, is the general approach of an opt-in boot parameter
(fips_exception) to keep the default behavior unchanged
acceptable, or would you prefer a different mechanism?

Thanks

Best regards
Jose Ignacio

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

[Johannes Berg]

Hi,

> What I would like and what we need is: data encryption stays in
> software (FIPS-compliant), WiFi connectivity works, and we accept
> that some management frame protection is not fully FIPS-validated.

Fair.

> > Well, it does work without MFP, so fundamentally the firmware can pass
> > data without having keys?
> 
> That is what I would expect, but in v1 I only re-enabled MFP_CAPABLE
> without passing any keys to firmware and got connection but no data
> traffic. Looking at the code, mac80211 SW crypto plumbing works
> correctly when drv_set_key() does not install keys in hardware,
> and the TX path sets IWL_TX_FLAGS_ENCRYPT_DIS for pre-encrypted
> frames. So the host side should handle it. My suspicion is that
> firmware changes its behavior when MFP is negotiated, expecting
> keys to be installed, and drops encrypted data frames it cannot
> decrypt instead of forwarding them to the host. The SEC_ENC_ERR
> messages I saw in v1 were likely from management frames, not data.
> Any guidance on this would help me take the right approach for v3.

I don't _think_ it does that. It does behave a bit differently for MFP,
but that's wrt. management frames.

Fundamentally, in this case the driver (even mac80211) shouldn't install
(data) keys to hardware.

> > That's not the point - the point is that there are different
> > dependencies and you didn't think about _why_ something is disabled.
> > Not all of this is all related to MFP.
> 
> Fair point. These dependencies were not documented in the original
> disabling commits, so I treated everything as a single block to
> revert. Could you clarify which features depend on MFP, which on
> HW crypto, and which on other reasons? That would help me get
> the separation right.

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.

> Spelled out: data encryption (PTK/GTK) must stay in software
> (FIPS-compliant). We accept that firmware-autonomous management
> frames (like AddBA) are not FIPS-protected. We accept reduced
> uplink throughput from missing TX aggregation. We do not need
> big A-MSDUs or WoWLAN. The goal is a working WPA3-SAE connection
> with FIPS-compliant data path.

Presumably that would mean IGTK/BIGTK can be offloaded and remain
working, but TK/GTK can't be known to the firmware since it's not FIPS
certified.

I mean, you _could_ push this further and keep almost all features: you
still give PTK/GTK to firmware but don't use the offload mechanisms for
data frames; though presumably then you'd not consider the result "good
enough" since then a non-certified component (the firmware/hardware)
holds the keys...?

> Also, is the general approach of an opt-in boot parameter
> (fips_exception) to keep the default behavior unchanged
> acceptable, or would you prefer a different mechanism?

I have no opinion on that, I guess the crypto folks should chime in
about that. Having something very obvious makes sense to me, vs. having
it at wifi or even driver level.

johannes

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

[Jose Ignacio Tornos Martinez]

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.

> Presumably that would mean IGTK/BIGTK can be offloaded and remain
> working, but TK/GTK can't be known to the firmware since it's not FIPS
> certified.

Ok, I will take this approach for v3: IGTK/BIGTK offloaded to
firmware, PTK/GTK software-only.

> I mean, you _could_ push this further and keep almost all features: you
> still give PTK/GTK to firmware but don't use the offload mechanisms for
> data frames; though presumably then you'd not consider the result "good
> enough" since then a non-certified component (the firmware/hardware)
> holds the keys...?

Ok, for our customers having the keys in a non-certified component
would not be acceptable. The simpler approach is better for this case.

> I have no opinion on that, I guess the crypto folks should chime in
> about that. Having something very obvious makes sense to me, vs. having
> it at wifi or even driver level.

Then I will keep the boot parameter approach and make sure to Cc the
crypto maintainers for their input.

I will work on the feature dependencies myself and come back with
a cleaner v3. Thanks for the guidance, very helpful.

Best regards
Jose Ignacio

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

[Johannes Berg]

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