BPF List
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: John Fastabend <john.fastabend@gmail.com>, bpf@vger.kernel.org
Cc: netdev@vger.kernel.org, ast@kernel.org, song@kernel.org,
	jonathan.lemon@gmail.com
Subject: Re: [bpf PATCH v2 0/8] Fixes for sockmap/tls from more complex BPF progs
Date: Wed, 15 Jan 2020 23:37:16 +0100	[thread overview]
Message-ID: <5cde124f-9ba4-b178-7fb6-e8340e23faee@iogearbox.net> (raw)
In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com>

On 1/11/20 7:11 AM, John Fastabend wrote:
> To date our usage of sockmap/tls has been fairly simple, the BPF programs
> did only well-defined pop, push, pull and apply/cork operations.
> 
> Now that we started to push more complex programs into sockmap we uncovered
> a series of issues addressed here. Further OpenSSL3.0 version should be
> released soon with kTLS support so its important to get any remaining
> issues on BPF and kTLS support resolved.
> 
> Additionally, I have a patch under development to allow sockmap to be
> enabled/disabled at runtime for Cilium endpoints. This allows us to stress
> the map insert/delete with kTLS more than previously where Cilium only
> added the socket to the map when it entered ESTABLISHED state and never
> touched it from the control path side again relying on the sockets own
> close() hook to remove it.
> 
> To test I have a set of test cases in test_sockmap.c that expose these
> issues. Once we get fixes here merged and in bpf-next I'll submit the
> tests to bpf-next tree to ensure we don't regress again. Also I've run
> these patches in the Cilium CI with OpenSSL (master branch) this will
> run tools such as netperf, ab, wrk2, curl, etc. to get a broad set of
> testing.
> 
> I'm aware of two more issues that we are working to resolve in another
> couple (probably two) patches. First we see an auth tag corruption in
> kTLS when sending small 1byte chunks under stress. I've not pinned this
> down yet. But, guessing because its under 1B stress tests it must be
> some error path being triggered. And second we need to ensure BPF RX
> programs are not skipped when kTLS ULP is loaded. This breaks some of
> the sockmap selftests when running with kTLS. I'll send a follow up
> for this.
> 
> v2: I dropped a patch that added !0 size check in tls_push_record
>      this originated from a panic I caught awhile ago with a trace
>      in the crypto stack. But I can not reproduce it anymore so will
>      dig into that and send another patch later if needed. Anyways
>      after a bit of thought it would be nicer if tls/crypto/bpf didn't
>      require special case handling for the !0 size.
> 
> John Fastabend (8):
>    bpf: sockmap/tls, during free we may call tcp_bpf_unhash() in loop
>    bpf: sockmap, ensure sock lock held during tear down
>    bpf: sockmap/tls, push write_space updates through ulp updates
>    bpf: sockmap, skmsg helper overestimates push, pull, and pop bounds
>    bpf: sockmap/tls, msg_push_data may leave end mark in place
>    bpf: sockmap/tls, tls_sw can create a plaintext buf > encrypt buf
>    bpf: sockmap/tls, skmsg can have wrapped skmsg that needs extra
>      chaining
>    bpf: sockmap/tls, fix pop data with SK_DROP return code
> 
>   include/linux/skmsg.h | 13 +++++++++----
>   include/net/tcp.h     |  6 ++++--
>   net/core/filter.c     | 11 ++++++-----
>   net/core/skmsg.c      |  2 ++
>   net/core/sock_map.c   |  7 ++++++-
>   net/ipv4/tcp_bpf.c    |  5 +----
>   net/ipv4/tcp_ulp.c    |  6 ++++--
>   net/tls/tls_main.c    | 10 +++++++---
>   net/tls/tls_sw.c      | 31 +++++++++++++++++++++++++++----
>   9 files changed, 66 insertions(+), 25 deletions(-)
> 

Applied, thanks!

      parent reply	other threads:[~2020-01-15 22:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11  6:11 [bpf PATCH v2 0/8] Fixes for sockmap/tls from more complex BPF progs John Fastabend
2020-01-11  6:11 ` [bpf PATCH v2 1/8] bpf: sockmap/tls, during free we may call tcp_bpf_unhash() in loop John Fastabend
2020-01-13 13:29   ` Jakub Sitnicki
2020-01-14  3:19     ` John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 2/8] bpf: sockmap, ensure sock lock held during tear down John Fastabend
2020-02-05 17:55   ` Jakub Sitnicki
2020-02-06  5:51     ` John Fastabend
2020-02-06 12:26       ` Jakub Sitnicki
2020-02-06 19:04         ` John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 3/8] bpf: sockmap/tls, push write_space updates through ulp updates John Fastabend
2020-01-12  1:00   ` Jonathan Lemon
2020-01-13 13:59   ` Jakub Sitnicki
2020-01-11  6:12 ` [bpf PATCH v2 4/8] bpf: sockmap, skmsg helper overestimates push, pull, and pop bounds John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 5/8] bpf: sockmap/tls, msg_push_data may leave end mark in place John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 6/8] bpf: sockmap/tls, tls_sw can create a plaintext buf > encrypt buf John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 7/8] bpf: sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining John Fastabend
2020-01-11  6:12 ` [bpf PATCH v2 8/8] bpf: sockmap/tls, fix pop data with SK_DROP return code John Fastabend
2020-01-15 22:37 ` Daniel Borkmann [this message]

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=5cde124f-9ba4-b178-7fb6-e8340e23faee@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=song@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