Le 2021-01-21 12:14, Jakub Sitnicki a écrit :
On Wed, Jan 20, 2021 at 10:06 PM CET, Alexei Starovoitov wrote:
There is also documentation in the kernel:
https://www.kernel.org/doc/html/latest/bpf/prog_sk_lookup.html
Thank you, I saw it, it's well written and very much explains it all.
Existing hook is placed before regular listening/unconnected socket
lookup to prevent port hijacking on the unprivileged range.
Yes, from the point of view of the BPF program. However from the point
of view of a legitimate service listening on a port that might be
blocked by the BPF program, BPF is actually hijacking a port bind.
That being said, if you install the BPF filter, you should know what you
are doing.
The suggestion above would work for my use case, but there is another
possibility to make the same use cases possible : implement in BPF
(or
allow BPF to call) the C and E steps above so the BPF program can
supplant the kernel behavior. I find this solution less elegant and
it
might not work well in case there are multiple inet_lookup BPF
programs
installed.
Having a BPF helper available to BPF sk_lookup programs that looks up a
socket by packet 4-tuple and netns ID in tcp/udp hashtables sounds
reasonable to me. You gain the flexibility that you describe without
adding code on the hot path.
True, if you consider that hot path should not be slowed down. It makes
sense. However, for me, it seems the implementation would be more
difficult.
Looking at existing BPF helpers
<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html> I found
bpf_sk_lookup_tcp and bpf_sk_lookup_ucp that should yield a socket from
a matching tuple and netns. If that's true and usable from within BPF
sk_lookup then it's just a matter of implementing it and the kernel is
already ready for such use cases.
Shanti
