fix iwd WPA3 (SAE) connection regression

[aenertia]

linux: fix iwd WPA3 (SAE) across all targets, harden rk_crypto
Enable CONFIG_PKCS8_PRIVATE_KEY_PARSER=y on all devices where it was
missing. iwd requires the PKCS8 parser to read modern certificate
and key formats during WPA3 SAE authentication — its absence was
the root cause of Status 77 rejections on RK3566, RK3399, and
other targets.

Devices updated: RK3399, RK3588, H700, SDM845, SM8250, SM8550,
SM8650. RK3326 and RK3566 already had this enabled.

Additionally, harden the rk3288_crypto driver's ahash scatter-gather
fallback function to reject zero-length SG entries and multi-fragment
scatterlists. This forces complex crypto payloads to the stable
ARM64_CE software implementation, preventing hash corruption during
SAE dragonfly handshakes. The rk3288_crypto driver only probes on
RK3399 (sole ROCKNIX target with a matching DT crypto node); the
patch applies harmlessly to other targets.

Remove the rk_crypto modprobe blacklists from RK3326 and RK3566 —
investigation confirmed the driver never probes on these devices
(no DT crypto node in px30.dtsi or rk356x.dtsi), making the
blacklists dead code. Revert the unnecessary CRYPTO_DEV_ROCKCHIP
y->m change on RK3566 for the same reason.

[porschemad911]

Forgive my ignorance, but if you are compiling as a module and then blacklisting that module, why include it at all?

[aenertia]

Yeah - I did contemplate this a bit. The rk_crypto is not entirely useless; it's just problematic for wpa3 handshakes it's a problem. I would rather include it. And it makes the diff cleaner as it's sub symbols don't get unselected.

In ideal world fixing it so it didn't break iwd would be nice. That would entailing trying to figure out if it's actually fixable in driver OR alternatively patching iwd to ignore it in preference of the ARM CE specifically.

Both those are more intrusive, so a blacklist seems like the better solution.

[aenertia]

Initial investigation looks like this is fixable in the driver for all platforms using rk_crypto; upstream. I think the current commit is valid for the moment. Happy to get this pushed but I will need a hand getting it submitted tl;dr follows:

TL;DR: Fix rk_crypto Hash Fallback for WPA3/SAE

The Issue: iwd WPA3 SAE handshakes time out or fail on RK3566/RK3326. This happens because iwd generates complex, multi-fragment scatter-gather (SG) lists that the Rockchip hardware crypto engine cannot process correctly.

Root Cause: The hardware hash fallback checker in rk3288_crypto_ahash.c (rk_ahash_need_fallback()) has a critical oversight:

1. It accidentally allows 0-length SG fragments to pass. When the DMA controller tries to copy 0 bytes, it hangs, resulting in kernel "DMA timeout" errors.
2. It allows multi-fragment SG lists to hit the hardware. The hardware engine/driver resets the internal MAC state between individual DMA transfers, which corrupts the final hash output and fails WPA3 authentication.

The Fix: Patch the fallback checker to proactively intercept 0-length elements and multi-fragment (sg_nents > 1) scatterlists. This gracefully routes iwd's complex payloads to the stable ARM64_CE software crypto fallback, fixing WPA3 while preserving hardware acceleration for standard bulk operations (like IPsec or dm-crypt).

Patch (drivers/crypto/rockchip/rk3288_crypto_ahash.c):

--- a/drivers/crypto/rockchip/rk3288_crypto_ahash.c
+++ b/drivers/crypto/rockchip/rk3288_crypto_ahash.c
@@ -19,17 +19,27 @@
 static bool rk_ahash_need_fallback(struct ahash_request *req)
 {
 	struct scatterlist *sg;
+	int sg_count = 0;
 
 	sg = req->src;
 	while (sg) {
-		if (!IS_ALIGNED(sg->offset, sizeof(u32))) {
+		if (!sg->length || !IS_ALIGNED(sg->offset, sizeof(u32))) {
 			return true;
 		}
 		if (sg->length % 4) {
 			return true;
 		}
+		sg_count++;
 		sg = sg_next(sg);
 	}
+
+	/* The Rockchip hardware hash engine cannot correctly maintain state
+	 * across multiple scatter-gather fragments. Force a software fallback
+	 * for complex SG lists to prevent MAC verification failures.
+	 */
+	if (sg_count > 1) {
+		return true;
+	}
+
 	return false;
 }

[aenertia]

am going to convert to draft and look at testing this will full DT enablement and a patch to fix it in the driver rather than via work around. Will update the draft as I go.

[aenertia]

Ok i'm happy with current state and validations i've done on it at this point. The 3399 is the device this likely needs testing on as the RCA patch to the rk-crypto affects it primarily; but I don't have one to confirm.