Re: RFC: a loadable plugin framework for external capture backends

[Vadim Goncharov <vadimnuclight () gmail com>]

On Thu, 01 Oct 2026 16:33:58 -0400
Michael Richardson <mcr () sandelman ca> wrote:

> Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>     > Jardin, the author of the PR, and Robin Jarry) are jointly moving the
>     > discussion of a libpcap plugin framework here, to the mailing list, as
>     >  
>
> So, I want to distinguish between a **plugin** vs a stable API/ABI that DPDK,
> VPP, etc. could work against.  Or a stable ABI that libpcap could work
> against.

+1

> (I also have many unpritable opinions about the OpenSSL provider interfaces)

+1
 
> So, let me suggest different interfaces which are relatively stable, and are
> already shared memory based: TPACKET_V3 and AF_XDP:
>   https://www.kernel.org/doc/html/latest/networking/af_xdp.html
>
> I recognize that these are two different but very similiar things, and I am
> unclear to what extent the Linux kernel treats them in similiar code paths.
> I believe that VPP, DPDK, etc. use AF_XDP to get packets from the kernel,
> and send them back to the device.  (I think that there are also still vendor
> proprietary paths?)

No, DPDK works in completely different way. An interface is detached from
kernel, it's DMA buffers are allocated inside huge pages (non-swappable),
driver (userland one!) places packets directly there, and main infinite loop
on each logical core polls that buffers eating 100% CPU even if there is no
traffic. That is, network interface disappears from system so there is nothing
to put into `tcpdump -i` - that's why entire subject is raised.

VPP has different backend, but usually DPDK one is chosen.

AF_XDP, on the other side, is from kernel side and kernel driver, interface
exists.

>     > Worth noting about this use case, because it bears directly on the
>     > security discussion below: the plugin needs *no elevated privileges at
>     > all*. The only resource it touches is a UNIX socket, over which it
>     > asks the grout daemon to start/stop a capture. Packets are then
>     > delivered through an ephemeral shared memory segment that the daemon
>     > owns. libpcap itself opens nothing privileged for this backend.  
>
> Yes, but what privileges libpcap/user needs to talk to DPDK is not really the
> concern.
>
> 1. some systems (distros) setuid on tcpdump.  I've never liked this, but I
>    understand it.
> 2. some systems (distros) use capabilities, set on the tcpdump executable.
> 3. but, many of us prefer to just sudo.
>
> I'd like to do more to split things up while not hurting performance too
> much.   OpenBSD has done some of this, but in it's own way.  I think that
> they are more concerned about the security around the dissectors, and I want
> that isolation as well.  Particularly for the "sudo" case.

4. On *BSD systems there is /dev/bpf* files - e.g. on my FreeBSD I just add my
user to have gid=0, do `chmod g+r /dev/bpf*` and now tcpdump runs from my user
without any "sudo" or binary tweaking. Don't know if OpenBSD changed something
here.

> The unix socket with ring buffers inteface I suggest above could also
> become the boundary between a front-end (filtering/printing) process, and the
> backend (some priveledge required to start) capture process.
> That is, libpcap could fork()/exec() or tickle some systemd thing, to get the
> access it needs, and then use the same ring ABI.

It would be nice if "file permissions" approach be generalized, may be with
unix sockets, so one will don't need "sudo tcpdump" even on Linux in generic
case.

> I would prefer --list-interfaces *NOT* attempt to load all the plugins in the
> default directory, and ask them for a list :-)
>
> That would otherwise be the best thing for users.
> That's mostly what I think wireshark UI users would want.
> Maybe a specific executable that can do this, returning JSON, would satisfy.

s/JSON/CBOR/

> Thanks.
> I'd like _tcpdump_ to drop any privilege if it is told to load a plugin.

Having it even not obtaining them ever (like on *BSD) is even better.

>     > - No privileged loading. Since the motivating backends need no
>     > elevated privileges (see section 2), libpcap could refuse to load
>     > plugins while running with elevated privileges, or drop those
>     > privileges first and only proceed if the drop succeeded. A single
>     > tcpdump binary could still do `tcpdump -i eth0` (opens a raw socket,
>     >  then drops) and `tcpdump -i grout:p0` (no privileges needed).  
>
> yes, I think everyone is in agreement here.
> I don't know if that will work for wireshark or other things.

AFAIR Wireshark already does capturing via separate process always (dumpcap).

-- 
WBR, @nuclight
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s