From: shaozhengchao <shaozhengchao@huawei.com>
To: Stanislav Fomichev <sdf@google.com>, Lorenz Bauer <oss@lmb.io>
Cc: <ast@kernel.org>, <daniel@iogearbox.net>, <bpf@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <yuehaibing@huawei.com>
Subject: Re: [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len
Date: Mon, 19 Sep 2022 18:55:35 +0800 [thread overview]
Message-ID: <5a3c5ea9-d557-6070-d778-1092f3c51257@huawei.com> (raw)
In-Reply-To: <CAKH8qBujKnFh8_g+npxHpo7RGFshus3N0iysmVBohTtG1X2yow@mail.gmail.com>
On 2022/9/17 23:46, Stanislav Fomichev wrote:
> On Wed, Sep 14, 2022 at 4:20 AM Lorenz Bauer <oss@lmb.io> wrote:
>>
>> Hi,
>>
>> I think this patch is causing user-space breakage, see [0].
>>
>> The gist is that we do BPF_PROG_RUN of a socket filter with 14 byte input to determine whether
>> BPF_PROG_RUN is available or not. I'll fix this in cilium/ebpf, but I think this patch
>> needs more work since users may be doing the same thing in their code.
>
> Ooops, sorry about that.
>
> Instead of rejecting len=0 data, we might accept the packet but add
> some safe header? I think that should be more backwards compatible?
> Zhengchao, something you can look into?
>
>
Sorry for the delay. I'm busy testing the TC module recently. I'm very
sorry for the user-space breakage.
The root cause of this problem is that eth_type_trans() is called when
the protocol type of the SKB is parsed. The len value of the SKB is
reduced to 0. If the user mode requires that the forwarding succeed, or
if the MAC header is added again after the MAC header is subtracted,
is this appropriate?
Zhengchao Shao
>> Thanks,
>> Lorenz
>>
>> 0: https://github.com/cilium/ebpf/pull/788
next prev parent reply other threads:[~2022-09-19 10:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 11:55 [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len Zhengchao Shao
2022-07-15 23:30 ` Stanislav Fomichev
2022-07-19 17:00 ` patchwork-bot+netdevbpf
2022-09-14 11:19 ` Lorenz Bauer
2022-09-17 15:46 ` Stanislav Fomichev
2022-09-19 10:55 ` shaozhengchao [this message]
2022-09-20 14:42 ` Lorenz Bauer
2022-09-21 8:48 ` shaozhengchao
2022-09-21 20:59 ` Stanislav Fomichev
2022-10-13 9:36 ` Lorenz Bauer
2022-10-13 10:44 ` shaozhengchao
2022-10-14 16:29 ` Lorenz Bauer
2022-10-14 16:55 ` sdf
2022-10-15 2:36 ` shaozhengchao
2022-11-03 21:07 ` Martin KaFai Lau
2022-11-03 21:36 ` Stanislav Fomichev
2022-11-03 22:42 ` Martin KaFai Lau
2022-11-03 22:58 ` Stanislav Fomichev
2022-11-09 21:43 ` Stanislav Fomichev
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=5a3c5ea9-d557-6070-d778-1092f3c51257@huawei.com \
--to=shaozhengchao@huawei.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=oss@lmb.io \
--cc=sdf@google.com \
--cc=yuehaibing@huawei.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 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).