Description
Redirect the packet to another net device of index ifindex. This helper is somewhat similar to bpf_clone_redirect(), except that the packet is not cloned, which provides increased performance.
Except for XDP, both ingress and egress interfaces
can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). Currently, XDP only supports redirection to the egress interface, and
accepts no flag at all.
The same effect can also be attained with the more generic bpf_redirect_map(), which uses a BPF map to store the redirect target instead of providing it directly to the helper.
Return For XDP, the helper returns XDP_REDIRECT on success or XDP_ABORTED on error. For other program types, the values are TC_ACT_REDIRECT on success or
TC_ACT_SHOT on error.
Ummm.
Okay. This is actually kinda scary if you aren't looking out for executables that make the bpf syscall. That's a lot of mischief one can get up to. Yeah, you'd have a bunch of reading to do, but that's some scary level access.
I've seen a few cases where BPF is used to outpace the TCP stack within the context of the same hunk of silicon (loopback or virtual network spaces) but I'd argue at that point you may be using the wrong tool for the wrong job if you're invoking network logic for what amounts to an inter-process communication issue.
This is one of my chief complaints with containers. There is nothing wrong with a bunch of trusted code running on the same machine. One doesn't need to invoke the networking stack for doing everything, even less so opening a gigantic hole in terms of allowing near arbitrary program composition in kernel space. This is the kind of needless complexity that just by existing presents a risk to everyone who doesn't know about it.
1 comment
[ 2.9 ms ] story [ 15.6 ms ] threadDescription Redirect the packet to another net device of index ifindex. This helper is somewhat similar to bpf_clone_redirect(), except that the packet is not cloned, which provides increased performance.
Except for XDP, both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). Currently, XDP only supports redirection to the egress interface, and accepts no flag at all.
The same effect can also be attained with the more generic bpf_redirect_map(), which uses a BPF map to store the redirect target instead of providing it directly to the helper.
Return For XDP, the helper returns XDP_REDIRECT on success or XDP_ABORTED on error. For other program types, the values are TC_ACT_REDIRECT on success or TC_ACT_SHOT on error.
Ummm.
Okay. This is actually kinda scary if you aren't looking out for executables that make the bpf syscall. That's a lot of mischief one can get up to. Yeah, you'd have a bunch of reading to do, but that's some scary level access.
I've seen a few cases where BPF is used to outpace the TCP stack within the context of the same hunk of silicon (loopback or virtual network spaces) but I'd argue at that point you may be using the wrong tool for the wrong job if you're invoking network logic for what amounts to an inter-process communication issue.
This is one of my chief complaints with containers. There is nothing wrong with a bunch of trusted code running on the same machine. One doesn't need to invoke the networking stack for doing everything, even less so opening a gigantic hole in terms of allowing near arbitrary program composition in kernel space. This is the kind of needless complexity that just by existing presents a risk to everyone who doesn't know about it.