Add a dynptr type for skb metadata for TC BPF #5744
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
Upstream branch: 0786654 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
5e1a4c1 to
91606c1
Compare
Author
|
Upstream branch: dc0fe95 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
43cd0dd to
f2c9097
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
91606c1 to
9e5d665
Compare
Author
|
Upstream branch: c80d797 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
f2c9097 to
9223edb
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
9e5d665 to
f86fd37
Compare
Author
|
Upstream branch: abdaf49 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
9223edb to
c1f1f41
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
f86fd37 to
2842450
Compare
Author
|
Upstream branch: 3ec8560 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
c1f1f41 to
57d4423
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
2842450 to
53b8665
Compare
Author
|
Upstream branch: 1274163 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
57d4423 to
72de14d
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
53b8665 to
26f4a08
Compare
Author
|
Upstream branch: d87fdb1 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
72de14d to
e44de61
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
26f4a08 to
032ad98
Compare
Add a dynptr type, similar to skb dynptr, but for the skb metadata access. The dynptr provides an alternative to __sk_buff->data_meta for accessing the custom metadata area allocated using the bpf_xdp_adjust_meta() helper. More importantly, it abstracts away the fact where the storage for the custom metadata lives, which opens up the way to persist the metadata by relocating it as the skb travels through the network stack layers. Writes to skb metadata invalidate any existing skb payload and metadata slices. While this is more restrictive that needed at the moment, it leaves the door open to reallocating the metadata on writes, and should be only a minor inconvenience to the users. Only the program types which can access __sk_buff->data_meta today are allowed to create a dynptr for skb metadata at the moment. We need to modify the network stack to persist the metadata across layers before opening up access to other BPF hooks. Once more BPF hooks gain access to skb_meta dynptr, we will also need to add a read-only variant of the helper similar to bpf_dynptr_from_skb_rdonly. skb_meta dynptr ops are stubbed out and implemented by subsequent changes. Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Now that we can create a dynptr to skb metadata, make reads to the metadata area possible with bpf_dynptr_read() or through a bpf_dynptr_slice(), and make writes to the metadata area possible with bpf_dynptr_write() or through a bpf_dynptr_slice_rdwr(). Note that for cloned skbs which share data with the original, we limit the skb metadata dynptr to be read-only since we don't unclone on a bpf_dynptr_write to metadata. Signed-off-by: Jakub Sitnicki <[email protected]>
dynptr for skb metadata behaves the same way as the dynptr for skb data with one exception - writes to skb_meta dynptr don't invalidate existing skb and skb_meta slices. Duplicate those the skb dynptr tests which we can, since bpf_dynptr_from_skb_meta kfunc can be called only from TC BPF, to cover the skb_meta dynptr verifier checks. Also add a couple of new tests (skb_data_valid_*) to ensure we don't invalidate the slices in the mentioned case, which are specific to skb_meta dynptr. Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Prepare for parametrizing the xdp_context tests. The assert_test_result helper doesn't need the whole skeleton. Pass just what it needs. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
We want to add more test cases to cover different ways to access the metadata area. Prepare for it. Pull up the skeleton management. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise reading from SKB metadata area in two new ways: 1. indirectly, with bpf_dynptr_read(), and 2. directly, with bpf_dynptr_slice(). Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Author
|
Upstream branch: dbe99ea |
Add tests what exercise writes to skb metadata in two ways: 1. indirectly, using bpf_dynptr_write helper, 2. directly, using a read-write dynptr slice. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise r/w access to skb metadata through an offset-adjusted dynptr, read/write helper with an offset argument, and a slice starting at an offset. Also check for the expected errors when the offset is out of bounds. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Demonstrate that, when processing an skb clone, the metadata gets truncated if the program contains a direct write to either the payload or the metadata, due to an implicit unclone in the prologue, and otherwise the dynptr to the metadata is limited to being read-only. Signed-off-by: Jakub Sitnicki <[email protected]>
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/991429=>bpf-next
branch
from
e44de61 to
bf13856
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
032ad98 to
728c457
Compare
Author
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=991429 irrelevant now. Closing PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: Add a dynptr type for skb metadata for TC BPF
version: 7
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429