linux-kernel - Re: [PATCH] net: Linn Ethernet Packet Sniffer driver

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]

Date:	Tue, 27 Jan 2015 15:46:53 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Stathis Voukelatos <stathis.voukelatos@...n.co.uk>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"abrestic@...omium.org" <abrestic@...omium.org>,
	f.fainelli@...il.com
Subject: Re: [PATCH] net: Linn Ethernet Packet Sniffer driver

Hi Stathis,

On 01/27/2015 12:15 PM, Stathis Voukelatos wrote:
> On 26/01/15 10:10, Daniel Borkmann wrote:
>>> Hello Daniel. Thank you for your feedback.
>>> Packet sockets could also be used for the driver interface to
>>> user space, however I think that both approaches would require the same
>>> amount of maintenance. We need to maintain a protocol consisting of
>>> a set of messages or commands that user space can use to communicate
>>> with the driver in order to configure the H/W and retrieve results.
>>> We could use packet sockets to send those messages  too, but I thought
>>> netlink already provides a message exchange framework that we could
>>> make use of.
>>
>> When using packet sockets and your driver as a backend feeding them,
>> users can see that there's an extra capturing/monitoring netdev present,
>> all libpcap-based tools such as tcpdump et al would work out of the box
>> w/o adapting any code, and as an admin you can also see what users/tools
>> are making of use of the device through packet sockets. I couldn't parse
>> the exact motivation from the commit message of why avoiding all this is
>> better?
>
> Just wanted to clarify some implementation details for your approach.
> - The driver would need to create and register two net_device instances.
> One for sniffing Ethernet TX packets and one for RX.

Hm, I would represent the whole device as a single monitoring-only netdev.
I'm somehow still missing the big advantage of all this as compared to
using packet sockets on the normal netdev? I couldn't parse that from your
commit message.

> - Would the control interface for the sniffer in that case need to be
> through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?

Nope, please have a look at Documentation/networking/packet_mmap.txt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/