Received-SPF: pass (google.com: domain of linux-crypto+bounces-189-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <312531ec-aba5-4050-b236-dc9b456c7280@linux.dev>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Sun, 19 Nov 2023 08:56:37 -0800
Message-ID: <CAADnVQLKsOs7LSFWGbAtJ8WfZjnQ0B_7gwFA-ZMdLPmukMGZ1A@mail.gmail.com>
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 18, 2023 at 3:46=E2=80=AFPM Vadim Fedorenko
<vadim.fedorenko@linux.dev> wrote:
>
> On 18/11/2023 18:35, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 3:32=E2=80=AFPM Vadim Fedorenko
> > <vadim.fedorenko@linux.dev> wrote:
> >>
> >> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> >>> On Sat, Nov 18, 2023 at 2:55=E2=80=AFPM Vadim Fedorenko <vadfed@meta.=
com> wrote:
> >>>>
> >>>> +/**
> >>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher c=
ontext structure
> >>>> + * @tfm:       The pointer to crypto_sync_skcipher struct.
> >>>> + * @rcu:       The RCU head used to free the crypto context with RC=
U 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.