netdev - Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEF2iQ_EO2kiwqwqGL=br4FjEt=9QF0MXs4ATzLes7uOQ@mail.gmail.com>
Date: Thu, 13 Nov 2025 16:35:07 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Simon Richter <Simon.Richter@...yros.de>
Cc: Stephen Hemminger <stephen@...workplumber.org>, Eric Biggers <ebiggers@...nel.org>, 
	netdev@...r.kernel.org, bpf@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code
 instead of AF_ALG

On Thu, 13 Nov 2025 at 09:51, Simon Richter <Simon.Richter@...yros.de> wrote:
>
> Hi,
>
> On 11/13/25 4:25 PM, Ard Biesheuvel wrote:
>
> > Also, I strongly agree with Eric that a syscall interface to perform
> > crypto s/w arithmetic that could easily execute in user space is
> > something that should have never been added, and creates portability
> > concerns for no good reason.
>
> Would it make sense to add crypto (and other transform) operations to
> the vdso, and make the decision whether the syscall is beneficial from
> there, depending on request/batch size (speed vs overhead tradeoff),
> data source/sink and available hardware?
>

No. User space has all the tools it needs to make his determination
itself, and OpenSSL (for example) already supports the 'afalg' engine,
which will use AF_ALG, but transparently fall back to software crypto
if the engine does not support the algorithm in question. So there is
prior art, and therefore no need to complicate the kernel for this.

Note that taking the SHA-1 of a BPF program is guaranteed to be way
below the threshold of being worth the overhead of using a crypto
offload engine, so in the context of this thread, it is kind of a moot
point.

> For example, "gzip -d" pulling data from a file and writing to a file
> will need to transfer the data to userspace first, process it there,
> then transfer it back to kernelspace so it can be written to a file.
>

That is a different matter, and AF_ALG does not really help here at
all. The crypto equivalent of what you describe already exists in
fscrypt, which can transparently encrypt files, making use of
whichever flavor of crypto is available, including inline crypto,
where the h/w accelerator is in the storage controller, and not in a
separate IP block. I'm not a file system expert, but AFAIK, some file
systems already support compression at the file level as well, in
which case h/w offload will be used where available, and the
compressed data never travels to user space.

Similarly, on the networking side, there are things like VPN
acceleration and kTLS, where the crypto offload is combined with the
networking hardware.

Discrete crypto offload hardware is simply not something that has a
lot of good use cases anymore.