Received-SPF: pass (google.com: domain of linux-crypto+bounces-213-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <87f5aa88-c2f2-4fce-95f9-39b04b2950de@linux.dev>
Date: Mon, 20 Nov 2023 18:08:59 +0000
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP
 programs
Content-Language: en-US
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Vadim Fedorenko <vadfed@meta.com>, Jakub Kicinski <kuba@kernel.org>,
 Martin KaFai Lau <martin.lau@linux.dev>, Andrii Nakryiko
 <andrii@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Mykola Lysenko <mykolal@fb.com>, Herbert Xu <herbert@gondor.apana.org.au>,
 Network Development <netdev@vger.kernel.org>,
 Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
 bpf <bpf@vger.kernel.org>
References: <20231118225451.2132137-1-vadfed@meta.com>
 <CAADnVQLBE1ex-B=F07R0xQKo-r22M0L6eiS8DjOAtsur-hEbFQ@mail.gmail.com>
 <862c832a-da98-4bef-80ef-8294be1d4601@linux.dev>
 <CAADnVQJ7__C06a=v0RfMvGQ_ohT21n=-1EUuaxqBe3aYU1izEg@mail.gmail.com>
 <312531ec-aba5-4050-b236-dc9b456c7280@linux.dev>
 <CAADnVQLKsOs7LSFWGbAtJ8WfZjnQ0B_7gwFA-ZMdLPmukMGZ1A@mail.gmail.com>
 <c1e3db50-50bd-d728-a911-58fa1c77506a@linux.dev>
 <CAADnVQJvfdPh7YXj30vsqkUF7a9M5SCaAkaB9qkmndS892Fu+w@mail.gmail.com>
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
In-Reply-To: <CAADnVQJvfdPh7YXj30vsqkUF7a9M5SCaAkaB9qkmndS892Fu+w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 20/11/2023 20:13, Alexei Starovoitov wrote:
> On Sun, Nov 19, 2023 at 4:22 PM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> wrote:
>>
>> On 19.11.2023 16:56, Alexei Starovoitov wrote:
>>> On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
>>> <vadim.fedorenko@linux.dev> wrote:
>>>>
>>>> On 18/11/2023 18:35, Alexei Starovoitov wrote:
>>>>> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
>>>>> <vadim.fedorenko@linux.dev> wrote:
>>>>>>
>>>>>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
>>>>>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <vadfed@meta.com> 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.

Ok, I got the idea. I'll make v6 more general, like AF_ALG, but it will
support only one type (skcipher) for now. Thanks!