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:	Tue, 23 Oct 2007 20:22:10 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jeff@...zik.org
Cc:	netdev@...r.kernel.org
Subject: Re: on the topic of alternate MAC addresses

From: Jeff Garzik <jeff@...zik.org>
Date: Tue, 23 Oct 2007 22:25:05 -0400

> 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).

I see your point.

However, it's not the virt clients that do this, it's the control
node (aka: domain 0) which has to manage these things.

It has to manage all of the global hardware resources and allocate
them out to itself and the clients anyways.

And this is why I think it's sufficient to just publish the list of
MAC addresses from the driver, and leave the allocation and policy
to the userland virtualizatin daemon running on the control node.

Let me know if you still disagree.
-
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