From: Yonghong Song <yhs@fb.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Lorenz Bauer <lmb@cloudflare.com>
Cc: Joe Stringer <joe@wand.net.nz>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>, Martin Lau <kafai@fb.com>
Subject: Re: call for bpf progs. Re: [PATCHv2 bpf-next 5/5] selftests: bpf: add test for sk_assign
Date: Thu, 26 Mar 2020 16:14:10 -0700 [thread overview]
Message-ID: <ac11345e-3036-4f88-96ab-9cff84b5d9ea@fb.com> (raw)
In-Reply-To: <20200326210719.den5isqxntnoqhmv@ast-mbp>
On 3/26/20 2:07 PM, Alexei Starovoitov wrote:
> On Thu, Mar 26, 2020 at 10:13:31AM +0000, Lorenz Bauer wrote:
>>>> +
>>>> + if (ipv4) {
>>>> + if (tuple->ipv4.dport != bpf_htons(4321))
>>>> + return TC_ACT_OK;
>>>> +
>>>> + ln.ipv4.daddr = bpf_htonl(0x7f000001);
>>>> + ln.ipv4.dport = bpf_htons(1234);
>>>> +
>>>> + sk = bpf_skc_lookup_tcp(skb, &ln, sizeof(ln.ipv4),
>>>> + BPF_F_CURRENT_NETNS, 0);
>>>> + } else {
>>>> + if (tuple->ipv6.dport != bpf_htons(4321))
>>>> + return TC_ACT_OK;
>>>> +
>>>> + /* Upper parts of daddr are already zero. */
>>>> + ln.ipv6.daddr[3] = bpf_htonl(0x1);
>>>> + ln.ipv6.dport = bpf_htons(1234);
>>>> +
>>>> + sk = bpf_skc_lookup_tcp(skb, &ln, sizeof(ln.ipv6),
>>>> + BPF_F_CURRENT_NETNS, 0);
>>>> + }
>>>> +
>>>> + /* We can't do a single skc_lookup_tcp here, because then the compiler
>>>> + * will likely spill tuple_len to the stack. This makes it lose all
>>>> + * bounds information in the verifier, which then rejects the call as
>>>> + * unsafe.
>>>> + */
>>>
>>> This is a known issue. For scalars, only constant is restored properly
>>> in verifier at this moment. I did some hacking before to enable any
>>> scalars. The fear is this will make pruning performs worse. More
>>> study is needed here.
>>
>> Of topic, but: this is actually one of the most challenging issues for
>> us when writing
>> BPF. It forces us to have very deep call graphs to hopefully avoid clang
>> spilling the constants. Please let me know if I can help in any way.
>
> Thanks for bringing this up.
> Yonghong, please correct me if I'm wrong.
Yes. The summary below is correct. For reference, the below bcc issue
documents some of my investigation:
https://github.com/iovisor/bcc/issues/2463
> I think you've experimented with tracking spilled constants. The first issue
> came with spilling of 4 byte constant. The verifier tracks 8 byte slots and
> lots of places assume that slot granularity. It's not clear yet how to refactor
> the verifier. Ideas, help are greatly appreciated.
I cannot remember exactly what I did then. Probably remember the spilled
size too. Since the hack is never peer reviewed, maybe my approach has bugs.
> The second concern was pruning, but iirc the experiments were inconclusive.
> selftests/bpf only has old fb progs. Hence, I think, the step zero is for
> everyone to contribute their bpf programs written in C. If we have both
> cilium and cloudflare progs as selftests it will help a lot to guide such long
> lasting verifier decisions.
Yes, this is inconclusive and I did not do any active investigation here
since just enhancing the non-const spill won't resolve the above issue.
But totally agree that if we had an implementation, we should measure
its impact on verifier speed.
next prev parent reply other threads:[~2020-03-26 23:14 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 5:57 [PATCHv2 bpf-next 0/5] Add bpf_sk_assign eBPF helper Joe Stringer
2020-03-25 5:57 ` [PATCHv2 bpf-next 1/5] bpf: Add socket assign support Joe Stringer
2020-03-26 6:23 ` Martin KaFai Lau
2020-03-26 6:31 ` Joe Stringer
2020-03-26 10:24 ` Lorenz Bauer
2020-03-26 22:52 ` Joe Stringer
2020-03-27 2:40 ` Joe Stringer
2020-03-25 5:57 ` [PATCHv2 bpf-next 2/5] bpf: Prefetch established socket destinations Joe Stringer
2020-03-26 21:11 ` Alexei Starovoitov
2020-03-26 21:45 ` Joe Stringer
2020-03-25 5:57 ` [PATCHv2 bpf-next 3/5] net: Track socket refcounts in skb_steal_sock() Joe Stringer
2020-03-25 5:57 ` [PATCHv2 bpf-next 4/5] bpf: Don't refcount LISTEN sockets in sk_assign() Joe Stringer
2020-03-25 10:29 ` Lorenz Bauer
2020-03-25 20:46 ` Joe Stringer
2020-03-26 10:20 ` Lorenz Bauer
2020-03-26 21:37 ` Joe Stringer
2020-03-25 5:57 ` [PATCHv2 bpf-next 5/5] selftests: bpf: add test for sk_assign Joe Stringer
2020-03-25 10:35 ` Lorenz Bauer
2020-03-25 20:55 ` Joe Stringer
2020-03-26 6:25 ` Martin KaFai Lau
2020-03-26 6:38 ` Joe Stringer
2020-03-26 23:39 ` Joe Stringer
2020-03-25 18:17 ` Yonghong Song
2020-03-25 21:20 ` Joe Stringer
2020-03-25 22:00 ` Yonghong Song
2020-03-25 23:07 ` Joe Stringer
2020-03-26 10:13 ` Lorenz Bauer
2020-03-26 21:07 ` call for bpf progs. " Alexei Starovoitov
2020-03-26 23:14 ` Yonghong Song [this message]
2020-03-27 10:02 ` Lorenz Bauer
2020-03-27 16:08 ` Alexei Starovoitov
2020-03-27 19:06 ` Joe Stringer
2020-03-27 20:16 ` Daniel Borkmann
2020-03-27 22:24 ` Alexei Starovoitov
2020-03-28 0:17 ` Andrii Nakryiko
2020-03-26 2:04 ` Andrii Nakryiko
2020-03-26 2:16 ` Andrii Nakryiko
2020-03-26 5:28 ` Joe Stringer
2020-03-26 6:31 ` Martin KaFai Lau
2020-03-26 19:36 ` Andrii Nakryiko
2020-03-26 21:38 ` Joe Stringer
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=ac11345e-3036-4f88-96ab-9cff84b5d9ea@fb.com \
--to=yhs@fb.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eric.dumazet@gmail.com \
--cc=joe@wand.net.nz \
--cc=kafai@fb.com \
--cc=lmb@cloudflare.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 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).