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? Thanks, John
