From: Eric Biggers <ebiggers@kernel.org>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>,
oss-security@lists.openwall.com,
Jan Schaumann <jschauma@netmeister.org>,
iwd@lists.linux.dev
Subject: Re: [oss-security] CVE-2026-31431: CopyFail: linux local privilege scalation
Date: Sun, 3 May 2026 23:43:46 -0700 [thread overview]
Message-ID: <20260504064346.GA112568@sol> (raw)
In-Reply-To: <16a713ee-4cf3-4f40-a532-8a937eaffd21@gmail.com>
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
next prev parent reply other threads:[~2026-05-04 6:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <afJorKIje4O6dXbH@netmeister.org>
[not found] ` <d6111caa-db61-498a-92cb-ea7a0aa0a5e2@ehuk.net>
[not found] ` <87se8dgicq.fsf@gentoo.org>
[not found] ` <afL-QhLfEKqHZqka@eldamar.lan>
[not found] ` <20260430071917.GB54208@sol>
[not found] ` <177abb5d-8ba9-4bb9-8b23-9fbc868ed3cd@gmail.com>
[not found] ` <20260501180028.GA2260@sol>
2026-05-01 19:24 ` [oss-security] CVE-2026-31431: CopyFail: linux local privilege scalation Demi Marie Obenour
2026-05-01 20:18 ` Eric Biggers
2026-05-02 0:21 ` Demi Marie Obenour
2026-05-02 3:35 ` Eric Biggers
2026-05-02 3:54 ` Eric Biggers
2026-05-02 6:39 ` Demi Marie Obenour
2026-05-02 4:52 ` AF_ALG hardening Demi Marie Obenour
2026-05-02 8:19 ` Simon Richter
2026-05-02 20:42 ` Demi Marie Obenour
2026-05-02 19:16 ` Eric Biggers
2026-05-04 19:01 ` Simon Richter
2026-05-04 19:54 ` Eric Biggers
2026-05-04 5:57 ` [oss-security] CVE-2026-31431: CopyFail: linux local privilege scalation Milan Broz
2026-05-04 6:13 ` Demi Marie Obenour
2026-05-04 6:43 ` Eric Biggers [this message]
2026-05-04 7:14 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260504064346.GA112568@sol \
--to=ebiggers@kernel.org \
--cc=demiobenour@gmail.com \
--cc=gmazyland@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=jschauma@netmeister.org \
--cc=oss-security@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox