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. (2) persisting a kernel api provided struct across program invocations then comes the need to persist the crypto state across invocations. for ciphers that require key expansion, such as AES, this expensive operation obviously can't be recalculated for every new packet. but struct skcipher_alg does not provide any method to provide pre-expanded keys, only setkey, which for AES and others implicitly generates the expanded keys. and adding another function to provide them is definitely the wrong design, as even regenerating the context on every invocation would wastefully cost cycles and allocation. and i'm sure as the bpf's kernel API surface area grows, there will be more kernel functionality exposed to bpf programs that necessitate struct persistence. so what i propose is: 2a) a new bpf map type that allows programs to store kernel api structs (containing pointers, etc) and inaccessible from userspace 2b) a way for a bpf program to inc/dec the ref count of kernel structs provided to it through APIs. programs would then be free to store these in maps. and even if they leak the pointers, doesn't matter because everything would be destroyed once the program is detached.
