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:	Sat, 28 Oct 2006 19:01:57 -0700
From:	Randy Dunlap <rdunlap@...otime.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Grant Grundler <grundler@...isc-linux.org>,
	Andrew Morton <akpm@...l.org>, Pavel Machek <pavel@....cz>,
	Greg KH <greg@...ah.com>,
	Stephen Hemminger <shemminger@...l.org>,
	Matthew Wilcox <matthew@....cx>, Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [patch] drivers: wait for threaded probes between initcall
 levels

On Sun, 29 Oct 2006 00:34:57 +0100 Alan Cox wrote:

> Ar Sad, 2006-10-28 am 22:48 +0200, ysgrifennodd Stefan Richter:
> > I hear network interfaces can be selected by their MACs, which are
> > globally unique and persistent. Most SCSI hardware has globally unique
> > and persistent unit properties too, and udev indeed uses them these days.
> 
> You hear incorrectly. The MAC address is only required to be *machine
> unique*, please see the 802.1/2 specification documents for more detail.
> Distinguishing by card MAC is a hack that works on some systems only.

I would have expected "most" instead of "some", but you have
different experiences than I do.  What spec requires a MAC address
to be machine-unique?

IEEE "makes it possible for organizations to employ unique individual 
LAN MAC addresses, group addresses, and protocol identifiers."

IEEE 802 goes on to say:
"The concept of universal addressing is based on the 
idea that all potential members of a network need to
have a unique identifier (if they are going to coexist 
in the network). The advantage of a universal address is
that a station with such an address can be attached to any 
LAN in the world with an assurance that the address is unique."

and then "recommended" (but not required):

"The recommended approach is for each device associated 
with a distinct point of attachment to a LAN to
have its own unique MAC address. Typically, therefore, 
a LAN adapter card (or, e.g., an equivalent chip or
set of chips on a motherboard) should have one unique 
MAC address for each LAN attachment that it can
support at a given time.

and then this part seems contrary to the machine-unique quality
that you mentioned (I guess--don't know--that this is what
Sun used to do ?):

"NOTE—It is recognized that an alternative approach has 
gained currency in some LAN implementations, in which the
device is interpreted as a complete computer system, 
which can have multiple attachments to different LANs. Under this
interpretation, a single LAN MAC address is used to 
identify all of the system’s points of attachment to the LANs in
question. This approach, unlike the recommended one, does 
not automatically meet the requirements of
IEEE Std 802.1D-1998 MAC bridging."


> SCSI is also unreliable for serial numbers because of USB, brain-dead
> raid controllers and other devices that fake the same ident for many
> devices.
> 
> There is another ugly too - many driver/library layers "know" that
> during boot the code is not re-entered so has no locking. Before you can
> go multi-probe you also have to fix all the locking in the drivers that
> have boot time specific functionality (eg IDE).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ