netdev - Re: [PATCH net-next] rtnl: Add support for netdev event to link 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]

Date:   Wed, 29 Mar 2017 09:37:45 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     vyasevic@...hat.com
CC:     David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] rtnl: Add support for netdev event to link messages

On 3/29/17, 5:23 AM, Vlad Yasevich wrote:
> [ resending to list.  hit the wrong reply button last time ]
>
> On 03/27/2017 06:58 PM, David Miller wrote:
>> From: Vladislav Yasevich <vyasevich@...il.com>
>> Date: Sat, 25 Mar 2017 21:59:47 -0400
>>
>>> RTNL currently generates notifications on some netdev notifier events.
>>> However, user space has no idea what changed.  All it sees is the
>>> data and has to infer what has changed.  For some events that is not
>>> possible.
>>>
>>> This patch adds a new field to RTM_NEWLINK message called IFLA_EVENT
>>> that would have an encoding of the which event triggered this
>>> notification.  Currectly, only 2 events (NETDEV_NOTIFY_PEERS and
>>> NETDEV_MTUCHANGED) are supported.  These events could be interesting
>>> in the virt space to trigger additional configuration commands to VMs.
>>> Other events of interest may be added later.
>>>
>>> Signed-off-by: Vladislav Yasevich <vyasevic@...hat.com>
>> At what point do we start providing the metadata for the changed
>> values as well?  You'd probably need to provide both the old and
>> new values to cover all cases.
> I don't think if that would be possible because of when events are triggered.
> We send these notifications after all the changes have already been made, so
> it might be tough to carry old data.
>
> Looking at just the two events I am supporting in this patch, we could actually
> supply the old mtu data through a NETDEV_PRECHANGEMTU event, if it is necessary.

But, NETDEV_PRECHANGEMTU will be a unnecessary notification to userspace without
changes. There are already enough notifications generated for links (I know you are not
suggesting adding it here)
> For the use cases I am looking at, it isn't usefull, but easy enough to add.
>
Most of the times a single notification can carry multiple changes, this helps user-space..by
cutting down on notifications in systems with large number of links. I don't see IFLA_EVENT attribute
handle multiple changes..

Given the number of attributes for which events are generated, I think a model where user-space
maintains a cache and diff's the new link object with the old one works best in all cases.