RFC: a loadable plugin framework for external capture backends

[Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Robin Jarry" <rjarry () redhat com>
>
> Date: Wed, 30 Sep 2026 22:28:45 +0200
>
> Hello,
>
> Following Denis Ovsienko's suggestion on GitHub PR #1659 [1], we 
> (Vincent 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 the tcpdump.org front page recommends for major changes. This 
> message is deliberately about the problem and the shape of a solution, 
> not about the code currently in the PR. Our goal is to reach agreement 
> on whether the idea is worth pursuing and, if so, on a specification we 
> can all reason about before any code is reviewed for merge.
>
> We will try to answer, up front, the four questions Denis raised.
>
>
> 1. The problem
> ==============
>
> Modern userspace dataplanes (DPDK-based routers such as grout, OVS-DPDK, 
> VPP, and similar) move packets entirely in userspace. Their interfaces 
> are invisible to the kernel, so `tcpdump -i <iface>` cannot open them as 
> a live source. Capturing traffic from a running dataplane today means 
> either a bespoke CLI tool per project, or building capture support 
> directly into libpcap. Existing remote-capture solutions such as rpcapd 
> do not help here either: they require the dataplane to write every 
> captured packet to a TCP/UDP socket, i.e. a system call and a copy per 
> packet, which is unacceptable on the multi-Mpps data path these 
> dataplanes are built to sustain.
>
> Building it into libpcap does not work well. The old in-tree DPDK 
> backend demonstrated this: it was pinned to DPDK 18.11, never followed 
> the DPDK API, was disabled by default because of the maintenance cost, 
> and has now been removed from libpcap 1.11.0 [2]. The underlying reason 
> is that these dataplanes expose fast-moving, unstable APIs whose release 
> cycle is independent from libpcap's. Compiling a backend for them into 
> libpcap ties the two cycles together: an API change breaks the libpcap 
> build, and fixing it needs a coordinated update of both projects.
>
> A plugin framework decouples the two. A dataplane project builds its own 
> pcap-<name>.so against its own headers, ships it with its own packages, 
> and upgrading the dataplane only means rebuilding the plugin, not 
> libpcap. If the plugin is absent or fails to load, libpcap keeps working 
> exactly as before. This is the same reason PAM, NSS, GStreamer, OpenSSL 
> providers and Mesa all converged on a loadable-module model.
>
>
> 2. A concrete, maintained use case
> ==================================
>
> To answer "which plugins, and who maintains them": grout (a DPDK-based 
> router hosted under the DPDK project [3]) has a draft plugin, 
> pcap-grout.so [4], that lets `tcpdump -i grout:p0` capture directly from 
> the dataplane. It is developed and maintained by the grout project, not 
> by The Tcpdump Group, and that is exactly the point of the framework: 
> the backend and its churn live with the dataplane, outside libpcap.
>
> 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.
>
>
> 3. The specification, and what the framework does and does not do
> =================================================================
>
> Denis is right that the PR lacks a specification, and that this is the 
> main blocker. Rather than defend the current code, we would like to use 
> the list to nail down the semantics first. Here are the questions 
> we think a spec must answer, with our current opinion on each as 
> a starting point for discussion:
>
> - Discovery. Where are plugins found, and in what order? (The PR uses 
>   a single compiled-in directory plus an environment override that is 
>   dropped under elevated privileges, like ld.so with LD_LIBRARY_PATH.)
>
> - Enumeration vs selection. Do plugins only contribute devices to 
>   pcap_findalldevs(), or can they intercept arbitrary device names? 
>   Our preference: a plugin owns a namespace prefix (e.g. "grout:") and 
>   is consulted only for names in its namespace. This makes "how do 
>   multiple plugins coexist" answerable by construction.
>
> - Parallelism / pre-emption. Denis asked how multiple plugins work in 
>   parallel or pre-empt each other. Our proposed answer: they do not 
>   interact at all. Each pcap_t is bound to exactly one backend chosen 
>   at create/activate time; plugins never see each other's handles. 
>   Anything else should be out of scope for a first version.
>
> - ABI. Plugins must not see pcap-int.h. The proposal is a versioned, 
>   narrow accessor API (pcap_plugin_*) so libpcap internals stay 
>   private and the plugin ABI is explicit and stable.
>
> - Failure behaviour. A plugin that is missing, unloadable, or reports 
>   a mismatched ABI version must be a silent no-op, never a fatal error 
>   for libpcap or its callers.
>
> What is eliminated by design vs left to plugin authors is itself part of 
> the spec, and we think the list is the right place to draw that line.
>
>
> 4. The attack surface
> =====================
>
> This is the part that most needs the group's judgement, and we do not 
> want to hand-wave it.
>
> The honest position is that dlopen()ing code into a process that may 
> hold capture privileges increases the attack surface, and the framework 
> must be built so that the increase is as close to zero as possible. 
> Concretely, the directions we would like to discuss:
>
> - Off by default. The loader should be a compile-time option, disabled 
>   by default, as fxlb already requested on the PR. Distributions and 
>   dataplane projects opt in; a stock libpcap build carries none of it.
>
> - 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).
>
> - Explicit, not implicit. Rather than libpcap silently scanning 
>   directories, the application could call an explicit 
>   pcap_load_plugins() after it has dropped privileges, keeping the 
>   caller in control.
>
> - Trusted location only. Plugins load only from a root-owned, 
>   non-user-writable directory; the environment override is ignored 
>   under elevated privileges, exactly as ld.so treats LD_LIBRARY_PATH.
>
> - Optional, on top: detached-signature verification against keys in 
>   a root-owned directory, for deployments that want it. Possibly 
>   redundant with distro package signing.
>
> We do not claim this is complete. The question "how much does the attack 
> surface grow, and what are the new risks and their mitigations" is 
> precisely what we would like the group's security-minded members to help 
> scope.
>
>
> 5. Maintenance burden
> =====================
>
> To Denis's concern that a framework nobody uses, or one whose plugins 
> become TTG's responsibility, would be an expensive mistake: we agree, 
> and we think the framework should be designed so that no plugin is ever 
> TTG's responsibility. Plugins live in and are maintained by their own 
> projects (grout being a concrete, active example). Inside libpcap the 
> recurring cost is just the loader and the accessor ABI. If we keep the 
> ABI narrow and the loader off by default, that cost stays small and 
> self-contained, and there are no repository-boundary problems inside 
> libpcap itself.
>
>
> Where we would like to go from here
> ===================================
>
> We would like this thread to converge on:
>
> a) whether the group is willing to have an external-backend plugin 
>    framework in libpcap at all;
>
> b) if so, an agreed specification of the semantics in section 3;
>
> c) an agreed security model along the lines of section 4.
>
> Only once (b) and (c) are settled would it make sense to revisit the 
> code in PR #1659 (which should probably also be split so that the plugin 
> framework is proposed on its own, separate from any specific backend).
>
> We are aware this will take time, and that libpcap 1.11.x is still 
> stabilising; there is no urgency on our side beyond wanting to do it 
> right. Thanks in advance for your feedback.
>
> Cheers,
>
> --
> Vincent Jardin -- Free Mobile, Iliad
> Robin Jarry -- Red Hat
>
> [1] https://github.com/the-tcpdump-group/libpcap/pull/1659
> [2] https://github.com/the-tcpdump-group/libpcap/pull/1697
> [3] https://github.com/DPDK/grout
> [4] https://github.com/DPDK/grout/pull/565
>
>
> --- End Message ---
_______________________________________________
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