Re: [PATCH 1/2] crypto: pcrypt - Remove pcrypt

Hello,

On 7/24/26 20:51, Eric Biggers wrote:
> On Fri, Jul 24, 2026 at 08:19:02PM +0200, Hendrik Donner wrote:
>>
>> so i'm now on 7.1.4 with
>>
>>    PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX to
>> work around hardware bug
>>
>> on top to be able to tune queue settings. And to have a working ethernet
>> in the first place, without the patch the NETDEV WATCHDOG resets the
>> card all the time due to queues stalling. But now more than 1 CPU are
>> serving IRQs.
>>
>> With pcrypt
>> (seqiv(rfc4106(pcrypt(gcm_base(ctr-aes-neonbs,ghash-lib))))):
>>
>> Upload:
>> [  4]   0.00-60.00  sec   901 MBytes   126 Mbits/sec
>>
>> Download:
>> [  4]   0.00-60.00  sec  1.23 GBytes   177 Mbits/sec
>>
>> Without pcrypt
>> (seqiv(rfc4106(gcm_base(ctr-aes-neonbs,ghash-lib)))):
>>
>> Upload:
>> [  4]   0.00-60.00  sec   679 MBytes  94.9 Mbits/sec
>>
>> Download:
>> [  4]   0.00-60.00  sec   674 MBytes  94.3 Mbits/sec
>>
>> So counterintuitively pcrypt matters more again. I repeated the tests a
>> few times, those numbers are fairly representative. Every run is over a
>> 60 sec window.
> 
> Thanks for trying it.  Perhaps this is related to the iperf3 test using
> only a single flow?  Does that reflect the real-world case for you?

probably flow related, i would need a different test setup to create
different flows, but for example single file downloads matter to our
userbase.

> 
> I'm also curious whether you're particularly attached to AES-GCM, or
> whether you've considered switching to ChaCha20Poly1305 which would be
> much faster on that CPU.  This could be done either by switching to
> "rfc7539esp(chacha20,poly1305)" within IPsec, or by just switching to
> WireGuard.
> 

Unfortunately the technical specification the system has to comply to
says IPSec and AES-GCM and/or AES-CBC with HMAC-SHA256. CBC is on its
way out though and barely seen in production anymore.

> If none of those are options for you and you do want pcrypt to be kept
> around, could you confirm that you're solely using 'crconf' (run as
> root) to enable it, and in particular you're not relying on the
> misfeature of also being able to enable it as an unprivileged user using
> AF_ALG?  We can keep it around for a bit longer if really needed, but
> the unprivileged stuff definitely has to go.  We should also keep in
> mind that pcrypt does not get tested very well (as the crypto self-tests
> just test serial use) and historically has had a lot of issues.
> 

For configuring the IPSec related templates only crconf is used in
production. On that kernel configuration AF_ALG is completely off.

Test environments use CONFIG_CRYPTO_USER_API_RNG only, everything else 
concerning AF_ALG is disabled.

Regards,
Hendrik

> - Eric