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

[Eric Biggers]

On Tue, Jul 21, 2026 at 08:59:21PM +0200, Hendrik Donner wrote:
> Hello,
> 
> On 7/14/26 00:32, Eric Biggers wrote:
> > pcrypt was originally intended to improve IPsec performance.  However,
> > it's no longer useful for that.  Reports from the rare cases that anyone
> > has actually tried to use it over the years indicate that it actually
> > reduces IPsec performance, e.g.:
> > 
> > * https://github.com/libreswan/libreswan/wiki/Internals:-Cryptographic-Acceleration#obsoleted-ipsec-accelerations
> > * https://users.strongswan.narkive.com/liqTaTq8/strongswan-problem-with-pcrypt
> > * https://unix.stackexchange.com/questions/594336/ipsec-multithreading-via-pcrypt-worse-than-single-thread
> > 
> > It's also undocumented and quite difficult to actually use.  Its design
> > is also broken, in that any unprivileged program can enable pcrypt
> > systemwide at any time (by instantiating it using AF_ALG).
> > 
> > Meanwhile, pcrypt has been a regular source of bugs, including at least
> > four that have received CVEs.
> > 
> > Let's just remove it.  No one seems to care about it anymore other than
> > people looking for vulnerabilities.
> > 
> 
> my company is a user. We have a hardware platform based on an IMX6 SoC
> using IPSec and configure pcrypt using crconf. Current performance
> difference:
> 
> iperf3 -c <IP> --time 60 -R
> 
> pcrypt:
> Download: 107 Mbits/sec
> 
> No pcrypt:
> Download: 59.3 Mbits/sec
> 
> iperf3 -c <IP> --time 60
> 
> pcrypt:
> Upload: 65.9 Mbits/sec
> 
> No pcrypt:
> Upload: 52.0 Mbits/sec
> 
> The relevant crypto templates are configured in early userspace and
> since i got curious, that has been the case since 2017.
> 
> Mostly using
> 
> pcrypt(gcm_base(ctr-aes-neonbs,ghash-generic))
> 
> nowadays, AES-CBC in the past/as a fallback option.
> 
> So at least on some platforms there is still a significant performance
> boots, at least for downloads in this case.

Thanks for bringing up your use case.

Have you looked into alternative solutions such as Receive Side Scaling
(https://docs.kernel.org/networking/scaling.html#rss-receive-side-scaling)?
AFAIK it's not just the crypto performance that makes pcrypt unnecessary
these days, but also the design of the networking layer.

I understand that i.MX6 doesn't have the ARMv8 crypto extensions.
However, surely you could at least use the NEON-optimized GHASH code?
Is there a reason you're not using it?

- Eric