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, 13 May 2014 09:30:41 -0700
From:	Jay Vosburgh <jay.vosburgh@...onical.com>
To:	Jiri Pirko <jiri@...nulli.us>
cc:	Or Gerlitz <ogerlitz@...lanox.com>,
	Veaceslav Falico <vfalico@...il.com>,
	Eyal Perry <eyalpe@...lanox.com>,
	netdev <netdev@...r.kernel.org>,
	Noa Osherovich <noaos@...lanox.com>
Subject: Re: bonding directly changes underlying device address

Jiri Pirko <jiri@...nulli.us> wrote:

>Tue, May 13, 2014 at 01:06:56PM CEST, ogerlitz@...lanox.com wrote:
>>Hi Jay, Veaceslav
>>
>>I see  now that alb_set_slave_mac_addr directly changes the
>>underlying device mac address without calling dev_set_mac_address
>>when running in TLB mode. Is that on purpose? if yes, can you explain
>>why?
>
>I believe that is a bug. dev_addr change should be always done using
>dev_set_mac_address.

	It may or may not be a bug today, but it's done this way on
purpose to work around the limitations of the system when the tlb mode
was implemented.

	The tlb mode wants to have each slave send with source MAC set
to a particular MAC assigned to the slave (which may or may not be the
slave's actual MAC address).  It does not need for slaves other than the
active slave to actually receive any packets (tlb only has load
balancing for TX, RX all goes to one slave), so programming the MAC into
the device was left out on purpose.

	The MAC change was done this way because, when the code was
originally written, many (perhaps most) devices / drivers could not
change their MAC address while open; it was common practice to program
the MAC in the device open function, and nowhere else.  This method
permits the tlb mode to do the MAC juggling on the TX side without
requiring the slave device be able to change its MAC while open (as the
alb mode requires).

>>I suspect this can lead to funny (or actually sad) bugs in networking
>>drivers, can we avoid that?

	Changing this would also remove support for the tlb mode from
any device that cannot change their MAC while open.  I don't know how
many devices that is (it's probably a small number nowadays), but if
it's not zero then an assessment on losing that support has to be made.

	-J

---
	-Jay Vosburgh, jay.vosburgh@...onical.com
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ