netdev - Re: [RFC PATCH net-next 3/3] packet: nlmon: virtual netlink monitoring device for packet sockets

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] [day] [month] [year] [list]

Message-ID: <51C33762.3000404@redhat.com>
Date:	Thu, 20 Jun 2013 19:09:54 +0200
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
CC:	davem@...emloft.net, tgraf@...g.ch, netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next 3/3] packet: nlmon: virtual netlink monitoring
 device for packet sockets

On 06/20/2013 05:46 PM, Stephen Hemminger wrote:
> On Thu, 20 Jun 2013 10:07:10 +0200
> Daniel Borkmann <dborkman@...hat.com> wrote:
>
>> On 06/19/2013 08:59 PM, Stephen Hemminger wrote:
>>> On Wed, 19 Jun 2013 20:04:46 +0200
>>> Daniel Borkmann <dborkman@...hat.com> wrote:
>>>
>>>> Currently, there is no good possibility to debug netlink traffic that
>>>> is being exchanged between kernel and user space. Therefore, this patch
>>>> implements a netlink virtual device, so that netlink messages will be
>>>> made visible to PF_PACKET sockets. Once there was an approach with a
>>>> similar idea [1], but it got forgotten somehow.
>>>
>>> ip monitor all
>>
>> Well, but this is only restricted to debugging rtnl and there are many other
>> subsystems using netlink. Also, it's not about low-level debugging netlink
>> in general from what I see from the code. So it's not really the same resp.
>> comparable to each other.
>
> I was thinking that having a more general monitor is great, and maybe you
> could reuse the similar concepts that already exist. I like the device idea
> or maybe teaching libpcap how to handle another input source like Patrick's
> mmap netlink would be better.

Ahh, okay, understood.

I think the device idea might be the cleanest solution. We have packet sockets
and they do exactly what we want and expect from them, they have all the features etc,
and user space would not even need to implement code. Thus adding more and more
functionality into af_netlink would be a bigger surgery and further bloat it up
with duplicate code, imho. By taking the approach with what I've proposed, we
have a clean segregation of functionality (as: packet sockets vs. netlink sockets),
thus keeping it simple and stupid, and not too complex.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html