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

[Hendrik Donner]

Hello,

On 7/21/26 21:50, Eric Biggers wrote:
> 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'm looking into this more, the IMX.6 is a bit limited with IRQ handling 
and queue distribution.

> 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?

I think it was historically not working well for us, retested:

NEON GHASH with pcrypt:

Download: 116 Mbits/sec
Upload: 74.3 Mbits/sec

NEON GHASH baseline:

Download: 90.7 Mbits/sec
Upload: 60.8 Mbits/sec

Looks better, still a ~15 Mbit improvement with pcrypt.

I want to point out that without IPSec our baseline is:

Download: 942 Mbits/sec
Upload: 942 Mbits/sec

Intel IGB ethernet.

Regards,
Hendrik

> - Eric