| 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
| ||
|
Message-ID: <471EAD01.5030502@garzik.org> Date: Tue, 23 Oct 2007 22:25:05 -0400 From: Jeff Garzik <jeff@...zik.org> To: David Miller <davem@...emloft.net> CC: netdev@...r.kernel.org Subject: Re: on the topic of alternate MAC addresses David Miller wrote: > I've been meaning to bring this up. > > A lot of cards that support multiple MAC addresses > in hardware provide pre-cooked lists of alternate > MAC addresses. This is either done via EEPROM, > NVRAM, or OpenFirmware device properties. > > For example, the Sun Neptune cards can provide an > array of up to 16 alternate MAC addresses per-port. > > We should provide a way to export these lists to > userspace. > > Perhaps an ethtool thing, Jeff? > > Once we have this, virtualization implementations can probe for and > use them. Currently they have no way to discover these things so > probably they just generate their own using some algorithm. hmmmm. Using ethtool isn't a big deal, but IMO you probably want more than just an exported list for the usage you described... it sounds like some sort of reservation system should be used, to note which MAC addresses are [not] in use? Then a virt client -- or anyone who wants multiple unicast addresses for whatever reason -- can let other clients to avoid MAC addresses 1, 7, or 13 (random examples). Jeff - 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