lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d44957f-8c09-47f3-93e0-78a1d34adfd0@kernel.org>
Date: Wed, 26 Nov 2025 13:59:59 +0100
From: Ahmad Fatoum <ahmad@...nel.org>
To: Vitor Soares <ivitro@...il.com>, linux-crypto@...r.kernel.org,
 linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Cc: horia.geanta@....com, pankaj.gupta@....com, gaurav.jain@....com,
 herbert@...dor.apana.org.au, john.ernberg@...ia.se,
 meenakshi.aggarwal@....com
Subject: Re: CAAM RSA breaks cfg80211 certificate verification on iMX8QXP

Hello Vitor,

On 26.11.25 11:55, Vitor Soares wrote:
> ++imx@...ts.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.

Just a shot in the dark, because I have no experience with i.MX8 beyond i.MX8M:

Is the CAAM cache-coherent on your SoC? If so does the DT specify dma-coherent
as it should? On i.MX8M, it's not cache-coherent, but on Layerscape it was and
the mismatch with the DT leads to symptoms matching what you are observing.

Off-topic remark: If you have performance comparison between running with and
without CAAM RSA acceleration, I'd be interested to hear about them.
At least for the hashing algorithms, using the Cortex-A53 (+ CE) CPU was a lot
faster than bothering with the CAAM "acceleration".

Cheers,
Ahmad



> 
> Regards,
> Vítor
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ