linux-kernel - Re: Network Device Naming mechanism and policy

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

Message-ID: <9b2b86520908060115k1035542cx1ad4102958eab780@mail.gmail.com>
Date:	Thu, 6 Aug 2009 09:15:16 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Jordan_Hargrave@...l.com
Cc:	linux-kernel@...r.kernel.org, Matt_Domsch@...l.com,
	Narendra_K@...l.com
Subject: Re: Network Device Naming mechanism and policy

On 8/5/09, Alan Jenkins <sourcejedi.lkml@...glemail.com> wrote:
> On 8/5/09, Jordan_Hargrave@...l.com <Jordan_Hargrave@...l.com> wrote:
>> This is from an old discussion several months ago:
>> http://lkml.org/lkml/2009/3/24/357
>> http://lkml.org/lkml/2009/3/24/380
>>
>> Basically the issue is that between a race in udev and PCI scan order the
>> ethX IDs may not
>> be consistent between reboots.  The idea is to use a mechanism similar to
>> how disks now can
>> be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids.
>>
>> The following patch will create a device node for network devices based
>> off
>> their ifindex;
>> udev can then use this device node for creating symlinks in /dev/net/xxxx
>> similar to the
>> way that disks now use by-label and by-path symlinks.
>>
>> Combining this with the biosdevname utility and patches to common network
>> utilities,
>> it could be possible to access ethernet devices by their PCI path or BIOS
>> Label.
>>
>> eg. ifconfig Embedded_NIC_1
>>
>> --- include/linux/major.h~	2009-07-30 18:34:47.000000000 -0400
>> +++ include/linux/major.h	2009-08-05 14:52:10.000000000 -0400
>> @@ -169,6 +169,7 @@
>>  #define IBM_FS3270_MAJOR	228
>>
>>  #define VIOTAPE_MAJOR		230
>> +#define NETDEV_MAJOR		234
>>
>>  #define BLOCK_EXT_MAJOR		259
>>  #define SCSI_OSD_MAJOR		260	/* open-osd's OSD scsi device */
>> --- net/core/net-sysfs.cx	2009-08-05 15:00:13.000000000 -0400
>> +++ net/core/net-sysfs.c	2009-08-05 15:01:20.000000000 -0400
>> @@ -11,6 +11,7 @@
>>
>>  #include <linux/capability.h>
>>  #include <linux/kernel.h>
>> +#include <linux/major.h>
>>  #include <linux/netdevice.h>
>>  #include <linux/if_arp.h>
>>  #include <net/sock.h>
>> @@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d
>>  	dev->class = &net_class;
>>  	dev->platform_data = net;
>>  	dev->groups = groups;
>> +	dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex);
>>
>>  	BUILD_BUG_ON(BUS_ID_SIZE < IFNAMSIZ);
>>  	dev_set_name(dev, "%s", net->name);
>>
>>
>> --jordan hargrave
>> Dell Enterprise Linux Engineering
>
> I guess opening such a device would yield ENODEV, which is
> unfortunately misleading.  Pity to add code just to get ENOTSUPP,
> but...
>
> Idea: allow opening the device.  You needn't provide any operations.
> The only effect would be to pin the ifindex.  That would allow tools
> to avoid racing with hot-unplug.
>
> Alan "Ideas are cheap" Jenkins

Oops, ifindex values aren't re-used (short of overflow).  So there
should be no need to "pin" an ifindex.  Nevermind.

> P.S. Is there any risk of ifindex overflowing when converted to a
> device minor number?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/