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:

quoted

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