netdev - Re: Send SFP event from kernel driver to user space (UDEV)

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:   Mon, 18 Nov 2019 11:54:31 +0000
From:   Shay Drory <shayd@...lanox.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Maor Gottlieb <maorg@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        "lennart@...ttering.net" <lennart@...ttering.net>,
        Saeed Mahameed <saeedm@...lanox.com>,
        lorian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "systemd-devel@...ts.freedesktop.org" 
        <systemd-devel@...ts.freedesktop.org>,
        Jiri Pirko <jiri@...lanox.com>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>
Subject: Re: Send SFP event from kernel driver to user space (UDEV)

On 11/18/2019 03:29, Andrew Lunn wrote:
> On Sun, Nov 17, 2019 at 11:46:15AM +0000, Shay Drory wrote:
>
> Hi Shay
>
> It would be good to Cc: the generic SFP code maintainers.

The suggested solution is not targeted for SFP drivers (see below),
but I added them to the Cc list.

>
>> Today, SFP inserted / removal event impacts only the kernel space drivers.
>> There are users who wishes to get SFP insert / removal in a udev-event
>> format for their application / daemons / monitors.
>> The naive way to implement this feature would be to create a sysfs file
>> that represents device SFP, to expose it under the netdev sysfs, and
>> to raise a udev event over it.
>> However, it is not reasonable to create a sysfs for each net-device.
>> In this letter, I would like to offer a new mechanism that will add a
>> support to send SFP events from the kernel driver to user space.
>> This suggestion is built upon a new netlink infrastructure for ethtool
>> currently being written by Michal Kubeckwhich called “ethtool-netlink”[1].
> So you are in no rush to make use of this? ethtool-nl seems to be
> making very slow progress.

I am looking for the correct solution that we can push to kernel open source.
The ethtool-nl seems like a good path. If you have another suggestion,
base on existing code, I will be glad to hear.

>
>> My suggestion is to do it by adding a function
>> (ethtool_sfp_insterted/removed(...)) to ethtool API, This function will
>> raise a netlink event to be caught in user space.
> What about the case of the SFP is inserted before the SFP is
> associated to a netdev? Similarly, the SFP is ejected when the SFP is
> not connected to a MAC. You don't have a netdev, so you cannot send an
> event. And SFF, which are never inserted or removed? SFPs have a
> different life cycle to a netdev. Do you care about this?

The feature is targeted to netdev users. It is expected from the user to query current state via
ethtool -m and afterwards monitor for changes over UDEV.

>
>> The design:
>>
>> - SFP event from NIC caught by the driver
>> - Driver call ethtool_sfp_inserted/removed()
>> - Ethtool generated netlink event with relevant data
>> - This event-message will be handled in the user-space library of UDEV
>> (for this purpose we would like to add a netlink infrastructure to UDEV
>> user-space library).
> Would you add just SFP insert/eject to UDEV. Or all the events which
> get sent via netlink? Link up/down, route add/remove, etc?

It makes sense to notify all events. What do you think?

>
> What sort of daemon is this anyway? Most networking daemons already
> have the code to listen to netlink events. So why complicate things by
> using UDEV?

That is a good point, we will discuss it internally.

>
> Is UDEV name space aware? Do you run a udev daemon in each network
> name space? I assume when you open a netlink socket, it is for just
> the current network namespace?

UDEV will follow netlink name-space.

>
>      Andrew

Thanks for your comments, Shay.