netdev - Re: [RESEND net-next PATCH v5] net: dummy: Introduce dummy virtual functions

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, 04 Jan 2017 14:09:14 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     phil@....cc
Cc:     netdev@...r.kernel.org, sd@...asysnail.net
Subject: Re: [RESEND net-next PATCH v5] net: dummy: Introduce dummy virtual
 functions

From: Phil Sutter <phil@....cc>
Date: Wed,  4 Jan 2017 14:44:06 +0100

> The idea for this was born when testing VF support in iproute2 which was
> impeded by hardware requirements. In fact, not every VF-capable hardware
> driver implements all netdev ops, so testing the interface is still hard
> to do even with a well-sorted hardware shelf.
> 
> To overcome this and allow for testing the user-kernel interface, this
> patch allows to turn dummy into a PF with a configurable amount of VFs.
> 
> Due to the assumption that all PFs are PCI devices, this implementation
> is not completely straightforward: In order to allow for
> rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> attached to the dummy netdev. This has to happen at the right spot so
> register_netdevice() does not get confused. This patch abuses
> ndo_fix_features callback for that. In ndo_uninit callback, the fake
> parent is removed again for the same purpose.
> 
> Joint work with Sabrina Dubroca.
> 
> Signed-off-by: Sabrina Dubroca <sd@...asysnail.net>
> Signed-off-by: Phil Sutter <phil@....cc>

First of all I really applaud any effort to make the kernel interfaces
more testable, and less dependent upon having specific pieces of hardware.

That being said, all of this seems to be fighting the problem from the
wrong direction.

The device layer is really kidding itself by having what seems like a
generic method in the form of dev_num_vf(), which actually just tests
the bus type and calls a bus specific function on a match.

There is no reason in the world that this cannot be done via proper
device method call, that any bus type or whatever can implement.

Then you don't need any of this stuff, you just hook up the proper
device method to the dummy device and you're good.