netdev - Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages

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: <20200218205441.GA24043@zorba>
Date:   Tue, 18 Feb 2020 20:54:56 +0000
From:   "Daniel Walker (danielwa)" <danielwa@...co.com>
To:     David Miller <davem@...emloft.net>
CC:     "zbr@...emap.net" <zbr@...emap.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages

On Tue, Feb 18, 2020 at 12:35:46PM -0800, David Miller wrote:
> From: "Daniel Walker (danielwa)" <danielwa@...co.com>
> Date: Tue, 18 Feb 2020 16:30:36 +0000
> 
> > It's multicast and essentially broadcast messages .. So everyone gets every
> > message, and once it's on it's likely it won't be turned off. Given that, It seems
> > appropriate that the system administrator has control of what messages if any
> > are sent, and it should effect all listening for messages.
> > 
> > I think I would agree with you if this was unicast, and each listener could tailor
> > what messages they want to get. However, this interface isn't that, and it would
> > be considerable work to convert to that.
> 
> You filter at recvmsg() on the specific socket, multicast or not, I
> don't understand what the issue is.

Cisco tried something like this (I don't know if it was exactly what your referring to),
and it was messy and fairly complicated for a simple interface. In fact it was
the first thing I suggested for Cisco.

I'm not sure why Connector has to supply an exact set of messages, one could
just make a whole new kernel module hooked into netlink sending a different
subset of connector messages. The interface eats up CPU and slows the
system if it's sending messages your just going to ignore. I'm sure the
filtering would also slows down the system.

Daniel