Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries
From: Vadim Fedorenko
Date: Tue Jul 07 2026 - 18:51:15 EST
On 07/07/2026 19:20, Eric Biggers wrote:
On Tue, Jul 07, 2026 at 04:01:13PM +0100, Vadim Fedorenko wrote:
cc +bpf
On 07/07/2026 06:34, Eric Biggers wrote:
BPF crypto was implemented using the lskcipher API, which doesn't seem
to be going anywhere. It supports only "arc4", "cbc(aes)", "ecb(aes)",
and only with unoptimized implementations.
Library APIs also have been found to be a much better approach, for a
variety of reasons, including reduced overhead, greater flexibility, and
having to be explicit about the crypto algorithms that are supported.
We can safely ignore the theoretical "arc4" support in BPF crypto as
unused, which leaves "cbc(aes)" and "ecb(aes)". Why these algorithms
were chosen, it's unclear. Regardless, I'll assume that "cbc(aes)" and
"ecb(aes)" need to continue to be supported for backwards compatibility.
That was done for single use case of decrypting small blocks in TC
layer with "cbc(aes)", with assumption of extending it later.
What protocol is using AES-CBC? And is the kernel encrypting or
decrypting the data elsewhere, or it is just routing an encrypted packet
and only the BPF program decrypts it?
That's a "home-made" part of UDP encapsulation, the kernel routes it
further based on the info collected by BPF decrypt program.
Does this mean the AES-ECB support is unnecessary and can be dropped?
Let's keep it if it doesn't hurt.
This change looks great, but it would be great to CC bpf folks just to
be aware of the refactoring.
Sure. I'm only looking to apply patches 1-13 for now; the rest (bpf,
fscrypt, keyrings, libceph, mac80211, macsec, mac802154, smb, ksmbd,
tipc) are proof of concept, showing how the library APIs can be used in
a wide range of kernel subsystems. I didn't want to spam the entire
series to 20 mailing lists. I'll resend them individually later.
Ok, cool. But you can keep my Rb anyways - I checked the code and run
tests.
Thanks!
- Eric