Re: CAAM RSA breaks cfg80211 certificate verification on iMX8QXP

[Vitor Soares <ivitro@gmail.com>]

++imx@lists.linux.dev

On Mon, 2025-11-24 at 19:03 +0000, Vitor Soares wrote:
> I’m currently investigating an issue on our Colibri iMX8QXP SoM running kernel
> 6.18-rc6 (also reproducible on v6.17), where cfg80211 fails to load the
> compiled-in X.509 certificates used to verify the regulatory database
> signature.
> 
> During boot, I consistently see the following messages:
>  cfg80211: Loading compiled-in X.509 certificates for regulatory database
>  Problem loading in-kernel X.509 certificate (-22)
>  Problem loading in-kernel X.509 certificate (-22)
>  cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
> 
> As part of the debugging process, I removed the CAAM crypto drivers and
> manually
> reloaded cfg80211. In this configuration, the certificates load correctly and
> the regulatory database is validated with no errors.
> 
> With additional debugging enabled, I traced the failure to
> crypto_sig_verify(),
> which returns -22 (EINVAL).
> At this stage, I’m trying to determine whether:
>  - This is a known issue involving cfg80211 certificate validation when the
> CAAM
> hardware crypto engine is enabled on i.MX SoCs, or
>  - CAAM may be returning unexpected values to the X.509 verification logic.
> 
> If anyone has encountered similar behavior or can suggest areas to
> investigate—particularly around CAAM—I would greatly appreciate your guidance.
> 
> Thanks in advance for any insights,
> Vítor Soares

Following up with additional debugging findings.

I traced the -EINVAL to rsassa_pkcs1_verify() in the PKCS#1 v1.5 verification
path. The check that fails expects a leading 0x00 byte in the RSA output buffer.
To investigate further, I poisoned the output buffer with 0xAA before the RSA
operation. CAAM RSA operation returns success, but the output buffer is never
written to.

During debugging, I loaded cfg80211 multiple times and observed that
sporadically one of the certificates gets verified correctly, but never both.

I confirmed that other CAAM operations work correctly by testing hwrng via
/dev/hwrng, which produces valid random data.

Given that CAAM reports success but does not populate the RSA output buffer, the
problem appears to be somewhere in the RSA execution flow (possibly in how the
result buffer is handled or returned), but I don’t have enough insight into
CAAM's RSA implementation or firmware interaction to pinpoint the exact cause.

As noted previously, blacklisting caam_pkc to force rsa-generic resolves the
issue.

Regards,
Vítor