Re: [PATCH bpf-next v3] bpf: crypto: Use AES-CBC and AES-ECB libraries

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 22, 2026 at 5:07 AM UTC, Eric Biggers wrote:
> On Tue, Sep 22, 2026 at 04:48:02AM +0000, Alexei Starovoitov wrote:
>> On Mon, Sep 21, 2026 at 09:04 PM Eric Biggers <ebiggers@kernel.org> wrote:
>> > +config BPF_CRYPTO
>> > +	def_bool y
>> > +	depends on BPF_SYSCALL
>> > +	depends on CRYPTO_LIB_AES_CBC
>> > +	depends on CRYPTO_LIB_AES_ECB
>> 
>> This will break the build with CRYPTO_AES=m.
>
> No, the new implementation only calls library code.  And if that library
> code isn't built-in, then this just doesn't get built at all, as per the
> 'depends on' lines.
>
> I'm not sure what you expected.  This could be a tristate, but that
> would mean it would be its own module, which doesn't seem conventional
> for kfuncs.

I see. peddle back. tristate is indeed overkill.

>> >  struct bpf_crypto_ctx {
>> > -	const struct bpf_crypto_type *type;
>> > -	void *tfm;
>> > -	u32 siv_len;
>> > +	enum bpf_crypto_algo_id algo;
>> > +	void *key;
>> 
>> No need for this. The bot was wrong.
>> Reading any field of struct bpf_crypto_ctx requires CAP_PERFMON.
>
> Okay, it sounded like a weird BPF quirk where the type system was being
> used to enforce a security boundary.  But if it's not needed, then
> that's helpful.  I'll go back to the original struct embedding.

+1