netdev - [RFC] bridge: MAC learning uevents

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

Date:   Thu, 8 Sep 2016 15:06:16 +0200
From:   "D. Herrendoerfer" <d.herrendoerfer@...rendoerfer.name>
To:     netdev@...r.kernel.org
Subject: [RFC] bridge: MAC learning uevents

Hello,

I'd like to start a discussion if it makes sense to add an optional feature

to the bridge MAC address learning code to generate kernel uevents for

every learned (added) and removed MAC address.

The (my) rationale behind this is, that I work with multiport SRIOV and 
MRIOV

network cards that cannot put each and every virtual port into promiscuous

mode, but they have the capability to register a large number of MAC 
addresses

to each interface.

These systems are host to a large number of kvm guests, that require 
network access.

To get around the problem I added two uevents to linuxbridge that would 
announce every

learned address to udev, and udev would register or remove  the MAC 
address to the

uplink device of the bridge.

The script may also add the required addresses for multicast and IPv6 if 
required.

The need for promiscuous mode on the card was gone. All I needed to do 
was to attach

the guests through a linuxbridge instead of directly to the card.

I may be missing something here - I'm pretty sure there I am, but is 
there any conceptual

reason why this should not be done this way ?

I'm porting my patch (for 3.10.0) to head, and will make it available, I 
just want some

valuable feedback as early as possible.

Thanks, D.Herrendoerfer