From: farbod shahinfar <fshahinfar1@gmail.com>
To: bpf@vger.kernel.org
Subject: Adjust packets in SK_SKB verdict program
Date: Fri, 23 Dec 2022 20:18:11 +0330 [thread overview]
Message-ID: <bc688911-79f1-d680-b06a-1ef837570032@gmail.com> (raw)
Hello everyone,
I have a question about sk_skb eBPF hook. Specifically my question is
about resizing packets in the sk_skb verdict programs using
`bpf_skb_adjust_room`. The issue is that even though I call this helper
and it returns successfully, after redirecting the packet, the size of
the packet received on the other side of the socket (userspace app) has
the original size.
I believe that this helper works properly and it really increases the
skb room. Also after invoking this helper, the verifier won't complain
about out of packet accesses. I think the issue is that the length would
be overwritten by the value from the stream parser before redirecting
the skb (look at [1]).
Looking at the implementation of `bpf_skb_adjust_room` helper function
(here [2]), it seems that at line [3] the stream parser value is updated
if there is a context for the TLS program. In my test environment this
update is not happening (I checked by adding printk). I am not
interested in kTLS, so it makes sense to me that this branch is not
taken. But it also makes me wonder if there should be a similar thing
for other sk_skb programs. Am I missing a point?
My question is, can a sk_skb verdict program resize the packet it redirects?
Just for the sake of testing, I added some changes to update the stream
parser length value with respect to room adjustment and it solves the
issue. But I wonder if I have missed the point.
[1] https://github.com/torvalds/linux/blob/master/net/core/skmsg.c#L664
[2] https://github.com/torvalds/linux/blob/master/net/core/filter.c#L3536
[3] https://github.com/torvalds/linux/blob/master/net/core/filter.c#L3562
Sincerely,
Farbod
reply other threads:[~2022-12-23 16:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bc688911-79f1-d680-b06a-1ef837570032@gmail.com \
--to=fshahinfar1@gmail.com \
--cc=bpf@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