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

On Wed, Jul 22, 2026 at 06:12:16PM +0200, Hendrik Donner wrote:

Hello,

On 7/21/26 21:50, Eric Biggers wrote:

quoted

On Tue, Jul 21, 2026 at 08:59:21PM +0200, Hendrik Donner wrote:

quoted

Hello,

On 7/14/26 00:32, Eric Biggers wrote:

quoted

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.

Thanks!  Maybe Steffen and the other IPsec folks would have some advice
too.

quoted

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.

That already shows that about two-thirds of the improvement you were
getting from pcrypt can be gotten just by using the correct GHASH
implementation for the platform (59.3 => 90.7 download, vs 59.3 => 107;
and 52.0 => 60.8 upload, vs 52.0 => 65.9).

And with that new baseline, for downloads, pcrypt adds just 28% more
throughput (90.7 => 116) rather than 80% as it did before (59.3 => 107).

It seems clear that the usefulness of pcrypt rapidly decreases as the
actual crypto gets faster.

Note: we've been enabling crypto optimizations by default in recent
kernels, so that people can no longer use the generic code by accident.
For example in v7.1 and later, GHASH optimizations are always enabled.

I'm working on further optimizations to the AES-GCM code as well,
specifically implementing AES-GCM directly on all platforms without the
inefficient gcm_base template that is being used here.

So while maybe pcrypt does still help a bit on this platform for now,
the approach does seem quite dated and largely a workaround for
inefficiencies elsewhere in the stack (including systems where the
optimized crypto code is accidentally not enabled).

- Eric