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

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

[Victor Stewart]

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.


(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.

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

[Victor Stewart]

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.
>
>
> (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.

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

[John Fastabend]

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

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

[Victor Stewart]

On Mon, Jan 15, 2024 at 6:21 PM John Fastabend <john.fastabend@gmail.com> 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@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?

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