From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Martin KaFai Lau <martin.lau@linux.dev>,
Vadim Fedorenko <vadfed@meta.com>
Cc: netdev@vger.kernel.org, linux-crypto@vger.kernel.org,
bpf@vger.kernel.org, Victor Stewart <v@nametag.social>,
Jakub Kicinski <kuba@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Mykola Lysenko <mykolal@fb.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH bpf-next v8 1/3] bpf: make common crypto API for TC/XDP programs
Date: Thu, 25 Jan 2024 11:19:17 +0000 [thread overview]
Message-ID: <a682b902-37a2-4d43-8f39-56ca213f6663@linux.dev> (raw)
In-Reply-To: <3d2d5f4e-c554-4648-bcec-839d83585123@linux.dev>
On 25/01/2024 01:10, Martin KaFai Lau wrote:
> On 1/15/24 2:08 PM, Vadim Fedorenko wrote:
>> +static int bpf_crypto_crypt(const struct bpf_crypto_ctx *ctx,
>> + const struct bpf_dynptr_kern *src,
>> + struct bpf_dynptr_kern *dst,
>> + const struct bpf_dynptr_kern *siv,
>> + bool decrypt)
>> +{
>> + u32 src_len, dst_len, siv_len;
>> + const u8 *psrc;
>> + u8 *pdst, *piv;
>> + int err;
>> +
>> + if (ctx->type->get_flags(ctx->tfm) & CRYPTO_TFM_NEED_KEY)
>
> nit. Does the indirect call get_flags() return different values?
> Should it be rejected earlier, e.g. in bpf_crypto_ctx_create()?
Well, that is the common pattern in crypto subsys to check flags.
But after looking at it second time, I think I have to refactor this
part. CRYPTO_TFM_NEED_KEY is set during tfm creation if algo requires
the key. And it's freed when the key setup is successful. As there is no
way bpf programs can modify tfm directly we can move this check to
bpf_crypto_ctx_create() to key setup part and avoid indirect call in
this place.
>
>> + return -EINVAL;
>> +
>> + if (__bpf_dynptr_is_rdonly(dst))
>> + return -EINVAL;
>> +
>> + siv_len = __bpf_dynptr_size(siv);
>> + src_len = __bpf_dynptr_size(src);
>> + dst_len = __bpf_dynptr_size(dst);
>> + if (!src_len || !dst_len)
>> + return -EINVAL;
>> +
>> + if (siv_len != (ctx->type->ivsize(ctx->tfm) +
>> ctx->type->statesize(ctx->tfm)))
>
> Same here, two indirect calls per en/decrypt kfunc call. Does the return
> value change?
I have to check the size of IV provided by the caller, and then to avoid
indirect calls I have to store these values somewhere in ctx. It gives a
direct access to these values to bpf programs, which can potentially
abuse them. Not sure if it's good to open such opportunity.
>
>> + return -EINVAL;
>> +
>> + psrc = __bpf_dynptr_data(src, src_len);
>> + if (!psrc)
>> + return -EINVAL;
>> + pdst = __bpf_dynptr_data_rw(dst, dst_len);
>> + if (!pdst)
>> + return -EINVAL;
>> +
>> + piv = siv_len ? __bpf_dynptr_data_rw(siv, siv_len) : NULL;
>> + if (siv_len && !piv)
>> + return -EINVAL;
>> +
>> + err = decrypt ? ctx->type->decrypt(ctx->tfm, psrc, pdst, src_len,
>> piv)
>> + : ctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv);
>> +
>> + return err;
>> +}
>
next prev parent reply other threads:[~2024-01-25 11:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 22:08 [PATCH bpf-next v8 1/3] bpf: make common crypto API for TC/XDP programs Vadim Fedorenko
2024-01-15 22:08 ` [PATCH bpf-next v8 2/3] bpf: crypto: add skcipher to bpf crypto Vadim Fedorenko
2024-01-25 1:14 ` Martin KaFai Lau
2024-01-25 9:24 ` Herbert Xu
2024-01-15 22:08 ` [PATCH bpf-next v8 3/3] selftests: bpf: crypto skcipher algo selftests Vadim Fedorenko
2024-01-25 1:26 ` Martin KaFai Lau
2024-02-21 8:43 ` Jakub Sitnicki
2024-02-21 9:19 ` Jakub Sitnicki
2024-01-23 17:51 ` [PATCH bpf-next v8 1/3] bpf: make common crypto API for TC/XDP programs Vadim Fedorenko
2024-01-24 0:12 ` Martin KaFai Lau
2024-01-25 1:10 ` Martin KaFai Lau
2024-01-25 11:19 ` Vadim Fedorenko [this message]
2024-01-25 22:34 ` Martin KaFai Lau
2024-01-26 10:30 ` Vadim Fedorenko
2024-01-26 17:38 ` Vadim Fedorenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a682b902-37a2-4d43-8f39-56ca213f6663@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=v@nametag.social \
--cc=vadfed@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).