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

[Michael Richardson <mcr () sandelman ca>]

Vadim Goncharov <vadimnuclight () gmail com> wrote:
    >> 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.

So, the DPDK thing is completely different frm XDP.
I didn't know.  But, is DPDKI coding NIC registers directly?
I didn't think that, but it *is* speaking the native/hardware ring buffers,
is what you are saying?
Thus, there is no "standard" ring buffer code in DPDK today :-(

    >> 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.

I think that OpenBSD isolates all of the print_* functions in tcpdump into an
even less privileged process than the user.

    >> 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/

Oh, sure.  I way prefer CBOR too, but I see some value in a human being able
to read this output.

    >> > - 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).

I didn't think it always did that.
I guess if it's only one plugin per pcap_t, then wireshark could (maybe it
does) start a new dumpcap if it needs to change.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on rails    [
]       My working hours and your working hours may be different.            [
]  Please do not feel obligated to reply outside your normal working hours   [

_______________________________________________
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