On Thu, Jan 21, 2021 at 09:40:19PM +0100, Shanti Lombard wrote: > 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. Agree that a helper to lookup the inet_hash is probably a better way. There are some existing lookup helper examples as you also pointed out. I would avoid adding new hooks doing the same thing. The same bpf prog will be called multiple times, the bpf running ctx has to be initialized multiple times...etc. > > 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
