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

Message-ID: <49C9128E.6040202@trash.net>
Date:	Tue, 24 Mar 2009 18:04:14 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Dan Williams <dcbw@...hat.com>
CC:	Matt Domsch <Matt_Domsch@...l.com>, netdev@...r.kernel.org,
	linux-hotplug@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Network Device Naming mechanism and policy

Dan Williams wrote:
> On Tue, 2009-03-24 at 17:21 +0100, Patrick McHardy wrote:
>> I would classify this as a bug, especially the fact that udev doesn't
>> undo a failed rename, so you end up with ethX_rename. Virtual devices
>> using the same MAC address trigger this reliably unless you add
>> exceptions to the udev rules.
> 
> Any particular reason the MAC addresses are the same?  This came up a
> while ago with the 'dnet' device in the thread "Dave DNET ethernet
> controller".
> 
> If the MAC address isn't a UUID for the device, then *what* is?

Sometimes (I was referring to virtual devices) there may not be
one, thats correct.

> If there isn't one, then certainly udev can't be blamed for getting
> ordering or names wrong, because there's nothing to use to actually
> match up the device to a name, uniquely. 

I agree that udev can't do anything useful in that case. I would
prefer it it wouldn't even try though instead of messing with the
names and leaving a bunch of _rename devices around. Sure, I can
add a rule to disable it, but that shouldn't be necessary.

Generally, I'm wondering whether it should touch virtual network
devices at all since the MAC addresses are often not persistent,
sometimes not unique and the name might have already been chosen
explicitly by the administrator when creating the device.

Currently there are some rules to ignore a couple of known virtual
devices types. Are there actually cases where renaming virtual
devices is desired? Otherwise a more future-proof way than
blacklisting each type individually would be to add some attribute
informing udev that the device has no unique key and should be
ignored.

--
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/