netdev - Re: [RFC] hv_netvsc: automatically name slave VF network device

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:   Tue, 19 Dec 2017 12:44:25 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     netdev@...r.kernel.org, Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [RFC] hv_netvsc: automatically name slave VF network device

On Tue, 19 Dec 2017 12:32:34 -0800
Jakub Kicinski <kubakici@...pl> wrote:

> On Tue, 19 Dec 2017 11:35:37 -0800, Stephen Hemminger wrote:
> > Rename the VF device to ethX_vf based on the ethX as the
> > synthetic device.  This eliminates the need for delay on setup,
> > and the PCI (udev based) naming is not reproducible on Hyper-V
> > anyway. The name of the VF does not matter since all control
> > operations take place the primary device. It does make the
> > user experience better to associate the names.
> > 
> > Based on feedback from all.systems.go talk.
> > The downside is that it requires exporting a symbol from netdev
> > core which makes it harder to backport.
> > 
> > Signed-off-by: Stephen Hemminger <sthemmin@...rosoft.com>  
> 
> Why do you have to name the devices in the kernel space in the first
> place? :/  Why don't upstream the correct change to biosdevname like
> hardware vendors do?

biosdevname is dead, gone and wouldn't work on Azure (it dumpster dives in /dev/mem).
I assume you mean the modern application is udev, and it works but the name is meaningless
because it based of synthetic PCI information. The PCI host adapter is simulated
for pass through devices. Names like enp12s0.

Since every passthrough VF device on Hyper-V/Azure has a matching synthetic
network device with same mac address. It is best to have the relationship
shown in the name.

> 
> Your VF setup is really _not_ special, I don't understand why we are 
> OK with ignoring the standard practices.  Real enterprise distroes
> are very careful never to break the naming of interfaces and they keep
> the naming policy in user space.  Playing tricks in the kernel has every
> chance of breaking existing user setups.

Actually, Systemd folks said "naming policy is in userspace only because
kernel can't get it right". Also there is no uniformity in userspace
there are at least 5 systems trying to do network setup. And most of
them depend on eth0 (yes still). Fixing userspace is impossible.