[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SYBPR01MB63364E7BD7FE724E2225875DEE302@SYBPR01MB6336.ausprd01.prod.outlook.com>
Date: Sun, 3 May 2026 06:30:34 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
Richard Kettlewell <rjk@...raraq.uk>, Eric Biggers <ebiggers@...nel.org>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
Demi Marie Obenour writes:
>Can you provide benchmarks showing that the accelerator is faster than the
>CPU on realistic workloads?
That could be tricky. The accelerator uses more hardware crypto than the CPU
on realistic workloads, would that do?
The following is from playing around on a few bits of hardware that were to
hand some years ago, so don't take it as gospel, but:
/* Check for the presence of crypto hardware support. This is something of
an exercise in futility because the crypto hardware is anything from
slightly slower (large data blocks) to much, much slower (more standard
small data blocks) than software due to the overhead of getting the data
through the API to and from the cryptologic, the cryptologic startup/
shutdown overhead, and in the case of /dev/crypto, in and out of the
kernel. The only place where it does matter is things like Cortex M3-
level SoCs, so a combination of lower-power CPUs, no instruction-level
assist for crypto, and direct hardware access from the RTOS with no
overhead where you just point the cryptologic at a block of memory and
say "process this".
However, people really want to see the fancy crypto hardware used even if
it yields a net loss in performance so we try and enable it if possible
unless it really is pointless, just a software emulation (many
/dev/crypto instances) where, assuming the crypto is provided by OpenSSL,
you can end up in a situation where OpenSSL is calling into a kernel
interface that then provides access to another, older and possibly
unpatched, copy of OpenSSL code that's doing the crypto.
[...]
So one solution would be to get the fingers-of-one-hand applications still
using the interface off it onto user-mode software-only and then make it
kernel-only, closing the door on the entire attack surface from user space.
Peter.
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.
