Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Eric Biggers]

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?

Does this mean the AES-ECB support is unnecessary and can be dropped?

> 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.

Thanks!

- Eric