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:	Wed, 17 Nov 2010 16:06:59 -0600
From:	Matt Domsch <Matt_Domsch@...l.com>
To:	linux-hotplug@...r.kernel.org, netdev@...r.kernel.org,
	narendra_k@...l.com
Cc:	jcm@...hat.com, notting@...hat.com
Subject: extended netdevice naming proposal

While this _is_ the original bikeshedding problem, as long as I'm
going to use biosdevname to change names for embedded NICs, perhaps I
can be so bold as to change them for USB add-in cards too?

There are quite a few dimensions to the problem:
* device location (onboard, PCI, other bus)
* multiple ports on a single add-in card
* with Network Partitioning (NPAR) and SR-IOV, the OS sees multiple
  network interfaces (physical or virtual interfaces) but a single external port
* the suffix .1234 currently used for vlans (ala vconfig)
* A single PCI device may drive multiple external ports

As such, here is a naming proposal, aimed to keep within 15
characters for most configurations.

(location)(slot)#(port)/(instance).(vlan)

location := NIC on Motherboard = net1, net2, net3, net4
   (note: people hated the TLA collision with 'lom', so avoiding that here).
         := PCI slot = pci1, pci2, pci3, pci4
 these correspond to chassis labels, information is available in
 $PIRQ, SMBIOS or ACPI, which biosdevname retrieves and uses.

For single- or multi-port cards in PCI slots, append #(port):
   pci1#1, pci1#2, pci1#3, pci1#4  for 4 ports on a card in PCI slot 1

There is currently no way to get this port info from BIOS.  Several people
have suggested using adding a PCI capabilities field to expose this
info in a standard way, but that's a ways off. Until then, biosdevname
can guess (assume ascending MAC order on the single card).

For NPAR/SR-IOV where the physical port is shared by several
instances, append /(instance):
   net1/1, net1/2 pci1#1/1, pci1#1/2,
   pci1#1/2, pci1#1/3, ...

For each of the above where vconfig sets up a vlan:
   pci1#/1.1000, pci1#1/2.1001, pci1#1/2.1003, pci1#1/3.1004, ...
vconfig simply appends .{vlan#} to the already  named device when creating a new vlan netdevice.

BIOS definitely doesn't know about these, as they aren't exposed until
after the OS is running, so the mechanism that creates them (such as
following modprobe ixgbevf) would have to, and I think that can be
done with a udev rule, if we can somehow expose the port number of the
underlying PF when we throw the message to udev on creation of the VF.

And of course, BIOS knows nothing about vlans, so vconfig would add that.


If we have no more than 99 PCI slots, no more than 99 ports on a
single card, no more than 999 instances/virtual functions (we need at
least 128, perhaps more than 256 at some point, so hex vs decimal
doesn't buy us much here), no more than 4k VLANs, we get:

len("pci99#99/999.4095") = 17

If we really have that many, we're in trouble in other ways, so let's
hope that's good enough.

Thoughts?  Overkill?

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists