All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Vadim Fedorenko <vadfed@meta.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Andrii Nakryiko <andrii@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Mykola Lysenko <mykolal@fb.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: add skcipher API support to TC/XDP programs
Date: Fri, 27 Oct 2023 18:02:54 +0100	[thread overview]
Message-ID: <b3f421b5-e9e2-4719-8529-56f2a0cf1cdf@linux.dev> (raw)
In-Reply-To: <20231026183509.471af050@kernel.org>

On 27/10/2023 02:35, Jakub Kicinski wrote:
> On Fri, 27 Oct 2023 00:29:29 +0100 Vadim Fedorenko wrote:
>>> Does anything prevent them from being used simultaneously
>>> by difference CPUs?
>>
>> The algorithm configuration and the key can be used by different CPUs
>> simultaneously
> 
> Makes sense, got confused ctx vs req. You allocate req on the fly.
> 
>>>> +	case BPF_DYNPTR_TYPE_SKB:
>>>> +		return skb_pointer_if_linear(ptr->data, ptr->offset, __bpf_dynptr_size(ptr));
>>>
>>> dynptr takes care of checking if skb can be written to?
>>
>> dynptr is used to take care of size checking, but this particular part is used
>> to provide plain buffer from skb. I'm really sure if we can (or should) encrypt
>> or decrypt in-place, so API now assumes that src and dst are different buffers.
> 
> Not sure this answers my question. What I'm asking is basically whether
> for destination we need to call __bpf_dynptr_is_rdonly() or something
> already checks that.

Well, I actually went to simpler implementation. As it's only needed for
dst buffer, move __bpf_dynptr_is_rdonly to helpers and use it to check
dst only and break earlier in case of error. If there will be other
customers of __bpf_dynptr_data_ptr helper, I'll implement it other way.

  parent reply	other threads:[~2023-10-27 17:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26  1:59 [PATCH bpf-next 1/2] bpf: add skcipher API support to TC/XDP programs Vadim Fedorenko
2023-10-26  1:59 ` [PATCH bpf-next 2/2] selftests: bpf: crypto skcipher algo selftests Vadim Fedorenko
2023-10-26 14:02   ` Daniel Borkmann
2023-10-26 18:20     ` Vadim Fedorenko
2023-10-26 21:47 ` [PATCH bpf-next 1/2] bpf: add skcipher API support to TC/XDP programs Jakub Kicinski
2023-10-26 23:29   ` Vadim Fedorenko
2023-10-27  1:35     ` Jakub Kicinski
2023-10-27 12:07       ` Vadim Fedorenko
2023-10-27 17:02       ` Vadim Fedorenko [this message]
2023-10-26 22:53 ` Alexei Starovoitov
2023-10-26 23: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=b3f421b5-e9e2-4719-8529-56f2a0cf1cdf@linux.dev \
    --to=vadim.fedorenko@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kuba@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=netdev@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.