netdev - Re: Port mirroring, v2 (RFC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c9db7b36-3855-1ac1-41b6-f7e9b91e2074@linaro.org>
Date:   Tue, 18 Jan 2022 11:37:05 -0600
From:   Alex Elder <elder@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Network Development <netdev@...r.kernel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: Port mirroring, v2 (RFC)

On 1/15/22 9:14 AM, Andrew Lunn wrote:
>> Below I will describe two possible implementations I'm considering.
>> I would like to know which approach makes the most sense (or if
>> neither does, what alternative would be better).
> 
> Hi Alex
> 
> Another corner of the kernel you could look for inspiration is usbmon.
> 
> https://www.kernel.org/doc/html/latest/usb/usbmon.html

Yes this looks very similar.  However IPA only carries
network traffic, unlike USB.  The "peripherals" (packet
sources) are all generating IP packets.

> This is similar to your misc char device, but it is actually
> implemented as a pseudo filesystem. It is intended for libpcap based
> applications and i've used it with tcpdump and wireshark. So exactly
> your use cases.

I suppose I could represent each possible source of packets
with a file system entry.  But that would require the IPA
driver to parse the received data and buffer each packet
separately (with others from its source).  Kind of messy.

I feel like it would be much better to just have one interface,
and have the filtering software exclude things that aren't
interesting.

> Because it is not a network device, the extra header does not cause
> problems, and there is no confusion about what the 'monitoring' netdevs
> are good for.

Yes, agreed.

> Since you are talking 5G and WiFi, you have a lot of packets
> here. Being able to use BPF with libpcap is probably useful to allow
> filtering of what packets are passed to user space. I've never looked
> at how the BPF core is attached to a netdev. But i suspect your extra

I haven't either.  But this too is something I've generally
thought I'd have to investigate.

> header could be an issue. So you are going to need some custom code to
> give it an offset into the packet to the Ethernet header?

Yes I think so.  No Ethernet header though.

> Humm, actually, you called the IPA the IP accelerator. Are these L2
> frames or L3 packets? Do you see 3 or even 4 MAC addresses in an
> 802.11 header? Two MAC addresses in an 802.3 header? etc.

L3 packets.  Except they are truncated if they're long, and they
have a metadata header prepended.

No MAC addresses, no 802.11 header.  Generally speaking, these
packets will start with 4 or 6 as the upper nibble of the first
byte (IP packet).  And of course, this follows the fixed-length
32-byte "status" header.

Here's are IPv4 and IPv6 ICMP examples.

00: 45 00 00 54 ac 5a 40 00 40 01 be 3c c0 00 00 02

10: 08 08 08 08 08 00 10 cf 11 c0 00 03 4f f4 e6 61

20: ac 14 08 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13

30: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23

40: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33

50: 34 35 36 37


00: 66 00 00 00 00 40 3a 70 26 07 77 00 00 00 00 2d

10: 00 00 00 01 08 08 08 08 26 07 fb 90 99 41 19 56

20: 00 c0 00 00 02 00 00 00 81 00 13 1f 11 c0 00 03

30: 4f f4 e6 61 ac 14 08 00 08 09 0a 0b 0c 0d 0e 0f

40: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

50: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f

60: 30 31 32 33 34 35 36 37



I'm basically ready to go on this, either way (using a
misc device, or--preferably--using a netdev).

I'm just trying to avoid getting that fully working,
then learning when I submit patches that someone thinks
it's the wrong way to go about it.

If a netdev is acceptable, my remaining issues are:
- Whether/how to avoid having the device be treated
   as if it needed support from the network stack
   (i.e., as a "real" network interface, serving to
   send and receive packets).
- Similar, whether there are special configuration
   options that should be used, given the device's
   purpose.
- What to call this functionality.  I'll avoid "mirror"
   and will try to come up with something reasonable,
   but suggestions are welcome.

Thanks.

					-Alex

>         Andrew
>