Re: AF_ALG hardening

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 7336 bytes --]

On 5/2/26 04:19, Simon Richter wrote:
> Hi,
> 
> On 5/2/26 13:52, Demi Marie Obenour wrote:
> 
>>> Of course, it'll also be a fair a bit of work, and unfortunately I also
>>> expect pushback from people who (incorrectly IMO) think that AF_ALG
>>> performance is important, even moreso than security.
> 
> AF_ALG performance (time/power) is important in the way that it's 
> literally the only point to its existence. If all it provides is extra 
> overhead over a software implementation, then it makes no sense to keep it.

The only reason for keeping it is for compatibility with existing
userspace.

>> If one cares about crypto offload performance, they would be better
>> served by creating a better interface to it than AF_ALG.  AF_ALG is
>> a horrible API with (presumably) tons of overhead.  I know the QAT
>> driver and an Nvidia BlueField DPU accelerator driver both bypass it.
> 
> The API is designed to be zerocopy, that's why it's this horrible 
> combination of socket API and splice(). The general assumption here is 
> that it does not make sense to offload small requests in the first 
> place, and application programmers are aware of that.
> 
> The use case is "I have a file or pipe full of data and a device with a 
> kernel driver that should process it, can we somehow avoid copying the 
> data to userspace only to immediately copy it back to kernelspace?"
> 
> This copying is even more silly if the actual question I have in 
> userspace is "what is the SHA256 checksum of this file?" or "what is the 
> SHA256 checksum of the string 'blob 8794311528\0' followed by this 
> file?" (where you can see why anyone would ask such a silly question and 
> prefer to use the dedicated hardware that processes 24 GB/s over the CPU 
> at 100 MB/s)

Do you have a specific device that has such hardware and can use an
upstream kernel?  I have yet to see any concrete examples.

>> Furthermore, AF_ALG only supports symmetric algorithms.  These
>> algorithms are inexpensive in software, so the cost of going to an
>> accelerator and back is enormous compared to the cost of a single
>> operation.
> 
> Yes, initial setup cost is high, so this only makes sense for large 
> requests or batches (submitting individual requests is generally cheap, 
> the difficulty is ensuring the data is accessible to the hardware).
> 
> That's also why there are no asymmetric algorithms: these aren't 
> generally used on large amounts of data, so it's never worth it to 
> offload these.

Asymmetric cryptography is far more expensive than symmetric
cryptography.  Tens of microseconds or more on a high-end CPU
I believe.

That is more than enough time to justify going to an accelerator and
back, if the accelerator can do the job significantly faster.

> It would make sense to offload asymmetric algorithms if there was a 
> secure key storage inside the device, but AFAIK the API does not support 
> that, or even the notion of on-device contexts.
> 
> It is not a good API, and it sits on top of the ahash/acomp/acrypt 
> interfaces which are also unfriendly to accelerator hardware.

Not surprised.

>> For offload to even a very fast accelerator to make sense,
>> one must be able to deeply pipeline requests.  However, this creates
>> a huge amount of additional complexity for software.
> 
> Software that has requirements like that is already complex -- if I have 
> a few thousand workload packets, I need a worker pool.

Or a thread-per-core architecture.

> If I don't have these requirements, then indeed I am better off with a 
> software-only solution in userspace, because it is not relevant from a 
> performance standpoint.
> 
>> Asymmetric accelerators also don't have a better alternative in the
>> form of inline encryption hardware.
> 
> Quite a number of architectures do not have inline encryption support, 
> and these are more likely to use offload hardware even for smaller 
> requests (e.g. for power saving).

Please provide a real-world example where that using the accelerator
really does save power compared to running the cryptography on the CPU.

>> I think a high performance interface to hardware cryptography (and,
>> more importantly, compression) would look much more like RDMA.
>> There would be a kernel driver that did the bare minimum to provide
>> isolation between userspace programs, and a userspace driver that
>> was responsible for abstracting over the hardware.
> 
> Offload hardware comes in two flavours: the high-throughput kind, built 
> into devices where no one cares about power, and the 
> lower-power-than-the-CPU-doing-it kind.

Again, please provide benchmarks.  I have yet to see a real-world
example where the accelerator is faster for short (read: realistic)
message sizes.  Eric Biggers has provided many where it is far slower,
and didn't find any situation where it saved power.

For very long messages, yes, it can be faster.  But I have yet to
see a situation where (a) performance for large files matters and (b)
there is an accelerator worth using.

Network and storage encryption is obviously performance-critical,
but it uses small messages.  Furthermore, both of them are well-suited
to inline cryptographic engines, which are much more efficient.

I mostly associate large file encryption and hashing with things
like verifying software updates.  On large systems, this matters
because a human is waiting.  However, these systems are also ones
for which software cryptography is very fast.  On small systems,
I expect update validation to be much less performance-critical.

> The former can easily provide user contexts even in virtualized 
> environments, but the latter is generally found in systems that do not 
> even have an IOMMU. Either we have two distinct interfaces for these, or 
> we need one that can handle either.
> 
> My feeling is that no one is happy with either AF_ALG or the 
> asynchronous interfaces in general, so I think they should be removed 
> completely, and there should be a separate "offload" SIG that creates 
> new interfaces that are actually usable with current hardware.
> 
>  > 1. Get rid of zero-copy support (splice()).
>  > 2. Get rid of AIO support.
>  > 3. Only allow software implementations.
> 
> That makes sense if we're forced to keep the interface for now, but it 
> means that offload support through the crypto subsystem is completely 
> dead, and anyone wanting to support offload hardware needs to go 
> elsewhere. Can we get a definitive statement that this is intended?

AF_ALG is dead.  Much of the rest of the kernel is moving from the
crypto API to the software-only crypto library.

Offload is far more complex than software cryptography, so there needs
to be a substantial benefit to justify using it.  Have you seen any
real-world cases of this?  Inline encryption hardware (both in storage
controllers and in NICs) is definitely a win, but it doesn't use the
crypto API at all.

It's easy to provide synthetic benchmarks where offload is a win, but
synthetic benchmarks don't justify a giant CVE magnet.  If offload is a
win in the real world, then it should be possible to demonstrate this.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]