Re: More flexible BPF socket inet_lookup hooking after listening sockets are dispatched

[Shanti Lombard <shanti@mildred.fr>]

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