On Mon, Jan 15, 2024 at 6:21 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > Victor Stewart wrote: > > On Sat, Jan 13, 2024 at 2:31 PM Victor Stewart <v@nametag.social> wrote: > > > > > > i was just brainstorming at Vadim off mailing list about my desire to do AES > > > decryption of QUIC connection IDs in an XDP program, RE his pending > > > bpf crypto api patch series: > > > > > > https://lore.kernel.org/bpf/20231202010604.1877561-1-vadfed@xxxxxxxx/ > > > > > > i'm hoping to gather some thoughts on the below two roadblocks: > > > > > > > > > (1) crypto for preemption disabled bpf programs > > > > > > as he mentioned in the comments of 1/3 and to me directly, a non sleepable > > > bpf program is not allowed to allocate a crypto context. > > > > > > is it possible for this restriction to be lifted? > > > > > > if not what safeguards would be required to lift it? > > > > > > worst case maybe an API could be added for userspace to initialize the > > > context, as userspace must provide the key anyway. > > I'm trying to understand why this is "worst case" to setup the context > from userspace? Perhaps naively I haven't tried to code this up, but > it seems like a sensible workflow to have userspace generate the key and > also setup the context. Then have fastpath (XDP) use the context for > decrypting? yes i agree 100%. i think adding a new syscall flag + struct is probably the ideal design? syscall flag -> BPF_CRYPTO_CTX_CREATE struct { __aligned_u64 alg_name; // filter alg by synchronous, else return error __u8 alg_name_len; __u32 alg_type; __u32 alg_mask; __aligned_u64 cipher_key; __u8 cipher_key_len; __u8 array_idx; // etc... }; store the created bpf_crypto_ctx objects in an array in kernel/bpf/crypto.c (the same as bpf_crypto_types) and add accessors and make it all array/index based for performance reasons. up to the user to manage the indexes. > > Thanks, > John
