[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74e8e566-4f5e-4cd3-afa1-a66e288bf8f3@gmail.com>
Date: Mon, 4 May 2026 13:07:25 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: Richard Kettlewell <rjk@...raraq.uk>, oss-security@...ts.openwall.com
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
