Re: [RFC bpf-next] crypto for unsleepable progs + new persistent bpf map for kernel api structs

[John Fastabend <john.fastabend@gmail.com>]

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@meta.com/
> >
> > 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