All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Martin KaFai Lau <kafai@fb.com>, Daniel Borkmann <daniel@iogearbox.net>
Cc: Joanne Koong <joannekoong@fb.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, Kernel-team@fb.com
Subject: Re: [PATCH bpf-next v2 0/3] Add XDP support for bpf_load_hdr_opt
Date: Sat, 09 Oct 2021 00:20:27 +0200	[thread overview]
Message-ID: <87lf33jh04.fsf@toke.dk> (raw)
In-Reply-To: <20211007235203.uksujks57djohg3p@kafai-mbp>

Martin KaFai Lau <kafai@fb.com> writes:

> On Thu, Oct 07, 2021 at 11:25:29PM +0200, Daniel Borkmann wrote:
>> I tend to agree with Toke here that this is not generic. What has been tried
>> to improve the verifier instead before submitting the series? It would be much
>> more preferable to improve the developer experience with regards to a generic
>> solution, so that other/similar problems can be tackled in one go as well such
>> as IP options, extension headers, etc.
> It would be nice to improve verifier to recognize it more smoothly.  Would
> love to hear idea how to do it.

So as far as I could tell, the verifier blows up in part because when
there's multiple bounded loops in sequence the verifier gets into a
combinatorial explosion of exploring all paths through the first loop
combined with all paths through the second. So if we could teach the
verifier to recognise that each loop is a separate entity to avoid this,
I think looping through headers would be a lot easier.

As you can probably tell, though, there is quite a bit of handwaving in
the above, and I have no idea how to actually do this. Some kind of
invariant analysis, maybe? But is this possible in general?

> When adding the tcp header options for bpf_sockops, a bpf_store_hdr_opt()
> is needed to ensure the header option is sane.  When writing test to parse
> variable length header option, I also pulled in tricks (e.g. "#pragma unroll"
> is easier to get it work.  Tried bounded loop but then hits max insns and
> then moved some cases into subprog...etc).  Most (if not all) TCP headers
> has some options (e.g. tstamp), so it will be useful to have an easy way
> to search a particular option and bpf_load_hdr_opt() was also added to
> bpf_sockops.

So if we can't fix the verifier, maybe we could come up with a more
general helper for packet parsing? Something like:

bpf_for_each_pkt_chunk(ctx, offset, callback_fn, callback_arg)
{
  ptr = ctx->data + offset;
  while (ptr < ctx->data_end) {
    offset = callback_fn(ptr, ctx->data_end, callback_arg);
    if (offset == 0)
      return 0;
    ptr += offset;
  }
  
  // out of bounds before callback was done
  return -EINVAL;
}
   
This would work for parsing any kind of packet header or TLV-style data
without having to teach the kernel about each header type. It'll have
quite a bit of overhead if all the callbacks happen via indirect calls,
but maybe the verifier can inline the calls (or at least turn them into
direct CALL instructions)?

-Toke


  reply	other threads:[~2021-10-08 22:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 23:05 [PATCH bpf-next v2 0/3] Add XDP support for bpf_load_hdr_opt Joanne Koong
2021-10-06 23:05 ` [PATCH bpf-next v2 1/3] bpf/xdp: Add bpf_load_hdr_opt support for xdp Joanne Koong
2021-10-06 23:50   ` Song Liu
2021-10-06 23:05 ` [PATCH bpf-next v2 2/3] bpf/selftests: Rename test_tcp_hdr_options to test_sockops_tcp_hdr_options Joanne Koong
2021-10-06 23:47   ` Song Liu
2021-10-06 23:05 ` [PATCH bpf-next v2 3/3] bpf/selftests: Add xdp bpf_load_tcp_hdr_options tests Joanne Koong
2021-10-06 23:52   ` Song Liu
2021-10-07 14:41 ` [PATCH bpf-next v2 0/3] Add XDP support for bpf_load_hdr_opt Toke Høiland-Jørgensen
2021-10-07 20:57   ` Joanne Koong
2021-10-07 21:25     ` Daniel Borkmann
2021-10-07 23:52       ` Martin KaFai Lau
2021-10-08 22:20         ` Toke Høiland-Jørgensen [this message]
2021-10-11 18:43           ` Martin KaFai Lau
2021-10-12 14:11             ` Toke Høiland-Jørgensen
2021-10-12 20:51               ` Joanne Koong
2021-10-13 10:19                 ` Toke Høiland-Jørgensen
2021-10-19  0:00           ` Alexei Starovoitov
2021-10-19 16:02             ` Yonghong Song
2021-10-19 16:10             ` Toke Høiland-Jørgensen

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=87lf33jh04.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=Kernel-team@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=joannekoong@fb.com \
    --cc=kafai@fb.com \
    --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 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.