[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260504064346.GA112568@sol>
Date: Sun, 3 May 2026 23:43:46 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: Milan Broz <gmazyland@...il.com>, oss-security@...ts.openwall.com,
Jan Schaumann <jschauma@...meister.org>, iwd@...ts.linux.dev
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
On Mon, May 04, 2026 at 02:13:01AM -0400, Demi Marie Obenour wrote:
> > - It is used for benchmarking, where we actually need kernel crypto.
> >
> > As it will be used in real dm-crypt mapping later, benchmarking
> > userspace lib just does not make sense.
> > (Requiring CAP_SYS_ADMIN here is not such a big issue, and it is
> > a very rough test - but useful for relative comparison, not for the
> > real numbers.)
>
> Would an API to ask the kernel to benchmark its own algorithms work
> for this? That would be a more accurate benchmark as it removes
> syscall overhead.
For what it's worth, I've always been frustrated by
'cryptsetup benchmark' and the numbers that people report with it
because they underestimate the fast algorithms so significantly.
For example, on my desktop (if I enable AF_ALG so that it works) it
reports 15585 MiB/s for AES-256-XTS encryption.
Yet, a userspace port of the kernel's VAES+AVX512 optimized AES-256-XTS
assembly code runs at 33600 MiB/s: over twice as fast.
(Yes, encryption is that fast now on the newer AMD processors.)
So in this case most of the time is spent in AF_ALG overhead, not the
actual algorithm that the benchmark is supposed to be measuring.
(And this is yet another example of why going through AF_ALG instead of
just calling a userspace crypto library isn't very efficient...)
I know the cryptsetup folks consider this tolerable since 'cryptsetup
benchmark' is meant to be a rough estimate anyway. But I think it
clearly shows that AF_ALG has never been all that great for the
"benchmarking the kernel's crypto code" use case, either.
In the case of benchmarking done during kernel development, we've
actually already been solving that in a different way: adding KUnit
tests with benchmarks included.
But for benchmarking by end users, yes, I suppose if really needed it
could be done using a new UAPI. It would just provide the speed of each
algorithm and nothing else.
- Eric
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.
