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. > > > (2) persisting a kernel api provided struct across program invocations whoops sorry for my ignorance on point 2, i now see bpf_kptr_xchg exists. lots to learn here! so point 1 is the only roadblock? > > 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.
