From: Jakub Kicinski <kuba@kernel.org>
To: Julien Salleyron <julien.salleyron@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
Marc Vertes <mvertes@free.fr>
Subject: Re: [PATCH] net: tls: fix tls with sk_redirect using a BPF verdict.
Date: Tue, 28 Jun 2022 10:34:24 -0700 [thread overview]
Message-ID: <20220628103424.5330e046@kernel.org> (raw)
In-Reply-To: <20220628152505.298790-1-julien.salleyron@gmail.com>
On Tue, 28 Jun 2022 17:25:05 +0200 Julien Salleyron wrote:
> This patch allows to use KTLS on a socket where we apply sk_redirect using a BPF
> verdict program.
>
> Without this patch, we see that the data received after the redirection are
> decrypted but with an incorrect offset and length. It seems to us that the
> offset and length are correct in the stream-parser data, but finally not applied
> in the skb. We have simply applied those values to the skb.
>
> In the case of regular sockets, we saw a big performance improvement from
> applying redirect. This is not the case now with KTLS, may be related to the
> following point.
It's because kTLS does a very expensive reallocation and copy for the
non-zerocopy case (which currently means all of TLS 1.3). I have
code almost ready to fix that (just needs to be reshuffled into
upstreamable patches). Brings us up from 5.9 Gbps to 8.4 Gbps per CPU
on my test box with 16k records. Probably much more than that with
smaller records.
> It is still necessary to perform a read operation (never triggered) from user
> space despite the redirection. It makes no sense, since this read operation is
> not necessary on regular sockets without KTLS.
>
> We do not see how to fix this problem without a change of architecture, for
> example by performing TLS decrypt directly inside the BPF verdict program.
>
> An example program can be found at
> https://github.com/juliens/ktls-bpf_redirect-example/
>
> Co-authored-by: Marc Vertes <mvertes@free.fr>
> ---
> net/tls/tls_sw.c | 6 ++++++
> tools/testing/selftests/bpf/test_sockmap.c | 8 +++-----
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 0513f82b8537..a409f8a251db 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -1839,8 +1839,14 @@ int tls_sw_recvmsg(struct sock *sk,
> if (bpf_strp_enabled) {
> /* BPF may try to queue the skb */
> __skb_unlink(skb, &ctx->rx_list);
> +
> err = sk_psock_tls_strp_read(psock, skb);
> +
> if (err != __SK_PASS) {
> + if (err == __SK_REDIRECT) {
> + skb->data += rxm->offset;
> + skb->len = rxm->full_len;
> + }
IDK what this is trying to do but I certainly depends on the fact
we run skb_cow_data() and is not "generally correct" :S
next prev parent reply other threads:[~2022-06-28 17:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 15:25 [PATCH] net: tls: fix tls with sk_redirect using a BPF verdict Julien Salleyron
2022-06-28 17:34 ` Jakub Kicinski [this message]
2022-06-29 7:00 ` John Fastabend
2022-06-29 8:58 ` Julien Salleyron
2022-06-30 15:21 ` Vadim Fedorenko
2022-07-05 3:26 ` Ziyang Xuan (William)
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=20220628103424.5330e046@kernel.org \
--to=kuba@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=julien.salleyron@gmail.com \
--cc=mvertes@free.fr \
--cc=netdev@vger.kernel.org \
/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).