On 5/4/26 07:28, Richard Kettlewell wrote: > On 02/05/2026 23:32, Demi Marie Obenour wrote: >> On 5/2/26 15:13, Richard Kettlewell wrote: >>> On 01/05/2026 16:30, Demi Marie Obenour wrote: >>>> On 4/30/26 03:19, Eric Biggers wrote: >>>>> But I also hope this finally provides some more impetus for AF_ALG to be >>>>> deprecated and removed. It's a massive, largely pointless attack >>>>> surface which has been causing problems, including regular CVEs, ever >>>>> since it was added to the kernel in 2010. And of course it's gotten >>>>> even worse lately, with LLMs now being able to find the bugs. >>>>> >>>>> Userspace crypto libraries exist. There's no need to escalate to kernel >>>>> mode just to do some math. >>>> >>>> The only reason I can think of to keep it is for embedded systems >>>> with weak CPUs and crypto accelerators that are actually worth using. >>>> However, those seem to be very rare outside of things like routers, >>>> which run specialized distros like OpenWRT. Even when the accelerator >>>> exists and is worth using, AF_ALG is certainly not an efficient way >>>> to access it. >>> >>> I have that use case, although fortunately it's in a context where >>> splice() is disabled. But the requirement is for access to the SoC's >>> accelerator - the interface doesn't need to be via AF_ALG in particular, >>> it doesn't have to offer software crypto (and it might be better if it >>> didn't), and it needn't be independent of the specific hardware >>> (although in the bigger picture it'd be a shame if it wasn't). >> >> Can you provide benchmarks showing that the accelerator is faster >> than the CPU on realistic workloads? > > The consistent improvements in latency and throughput started around the > 2Kbyte block size (10-20%) and improved as blocks grew, with around 50% > latency reduction and 150% throughput increase at 250Kbyte blocks (which > is close to our message size limit). > > Obviously this reflects the hardware we are using (which has no AES > support in the application cores), outcomes may differ on other targets. > > ttfn/rjk
Can you use ChaCha20-Poly1305 or Adiantum instead of AES? That should be significantly faster on the CPU -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
