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). > > ttfn/rjk
Can you provide benchmarks showing that the accelerator is faster than the CPU on realistic workloads? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
