On Sun, Nov 19, 2023 at 4:22 PM Vadim Fedorenko
<vadim.fedorenko@xxxxxxxxx> wrote:
>
> On 19.11.2023 16:56, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
> > <vadim.fedorenko@xxxxxxxxx> wrote:
> >>
> >> On 18/11/2023 18:35, Alexei Starovoitov wrote:
> >>> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
> >>> <vadim.fedorenko@xxxxxxxxx> wrote:
> >>>>
> >>>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> >>>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <vadfed@xxxxxxxx> wrote:
> >>>>>>
> >>>>>> +/**
> >>>>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> >>>>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
> >>>>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> >>>>>> + * @usage: Object reference counter. When the refcount goes to 0, the
> >>>>>> + * memory is released back to the BPF allocator, which provides
> >>>>>> + * RCU safety.
> >>>>>> + */
> >>>>>> +struct bpf_crypto_lskcipher_ctx {
> >>>>>> + struct crypto_lskcipher *tfm;
> >>>>>> + struct rcu_head rcu;
> >>>>>> + refcount_t usage;
> >>>>>> +};
> >>>>>> +
> >>>>>> +__bpf_kfunc_start_defs();
> >>>>>> +
> >>>>>> +/**
> >>>>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
> >>>>>
> >>>>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
> >>>>> bpf users don't need to know the internal implementation details.
> >>>>> bpf_crypto_encrypt/decrypt() is clear enough.
> >>>>
> >>>> The only reason I added it was the existence of AEAD subset of crypto
> >>>> API. And this subset can also be implemented in bpf later, and there
> >>>> will be inconsistency in naming then if we add aead in future names.
> >>>> WDYT?
> >>>
> >>> You mean future async apis ? Just bpf_crypto_encrypt_async() ?
> >>
> >> Well, not only async. It's about Authenticated Encryption With
> >> Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
> >> ciphers with additional hmac function, like
> >> 'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
> >> difference of having Authenticated data in the encrypted block.
> >
> > and ? I'm not following what you're trying to say.
> > Where is the inconsistency ?
> > My point again is that lskcipher vs skcipher vs foo is an implementation
> > detail that shouldn't be exposed in the name.
>
> Well, I was trying to follow crypto subsystem naming. It might be easier for
> users to understand what part of crypto API is supported by BPF kfuncs.
>
> At the same we can agree that current implementation will be used for simple
> buffer encryption/decryption and any further implementations will have additions
> in the name of functions (like
> bpf_crypto_aead_crypt/bpf_crypto_shash_final/bpf_crypto_scomp_compress).
> It will be slightly inconsistent, but we will have to expose some implementation
> details unfortunately. If you are ok with this way, I'm ok to implement it.
but shash vs scomp is the name of the algo ? Didn't you use it as
the 1st arg to bpf_crypto_create() ?
Take a look at AF_ALG. It's able to express all kinds of cryptos
through the same socket abstraction without creating a new name for
every algo. Everything is read/write through the socket fd.
In our case it will be bpf_crypto_encrypt/decrypt() kfuncs.
