netdev - Re: [RFC net-next 3/6] ethernet: prestera: use eth_hw_addr_set

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:   Mon, 18 Oct 2021 07:19:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org, olteanv@...il.com, andrew@...n.ch,
        idosch@...sch.org, f.fainelli@...il.com, vkochan@...vell.com,
        tchornyi@...vell.com
Subject: Re: [RFC net-next 3/6] ethernet: prestera: use
 eth_hw_addr_set_port()

On Sat, 16 Oct 2021 14:19:18 -0700 Shannon Nelson wrote:
> On 10/15/21 12:38 PM, Jakub Kicinski wrote:
> > Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
> > of VLANs...") introduced a rbtree for faster Ethernet address look
> > up. To maintain netdev->dev_addr in this tree we need to make all
> > the writes to it got through appropriate helpers.
> >
> > We need to make sure the last byte is zeroed.
> >
> > Signed-off-by: Jakub Kicinski <kuba@...nel.org>

> > @@ -341,8 +342,8 @@ static int prestera_port_create(struct prestera_switch *sw, u32 id)
> >   	/* firmware requires that port's MAC address consist of the first
> >   	 * 5 bytes of the base MAC address
> >   	 */
> > -	memcpy(dev->dev_addr, sw->base_mac, dev->addr_len - 1);
> > -	dev->dev_addr[dev->addr_len - 1] = port->fp_id;
> > +	memcpy(addr, sw->base_mac, dev->addr_len - 1);
> > +	eth_hw_addr_set_port(dev, addr, port->fp_id);  
> 
> Notice in this case I think the original code is setting the last byte 
> to port->fp_id, found I think by a call to their firmware, not by adding 
> fp_id to the existing byte value.

Yeah, as mentioned in the commit message and discussed with Vladimir.
Notice that the memcpy is (,, size - 1) and the initial buf is zeroed.

> This is an example of how I feel a bit queezy about this suggested 
> helper: each driver that does something like this may need to do it 
> slightly differently depending upon how their hardware/firmware works.  
> We may be trying to help too much here.
> 
> As a potential consumer of these helpers, I'd rather do my own mac 
> address byte twiddling and then use eth_hw_addr_set() to put it into place.

This is disproved by many upstream drivers, I only converted the ones
that jumped out at me on Friday, but I'm sure there is more. If your
driver is _really_ doing something questionable^W I mean "special"
nothing is stopping you from open coding it. For others the helper will
be useful. 

IOW I don't understand your comment.

In fact if someone is "afraid" of others refactoring their driver or
can't provide timely feedback (ekhm, prestera people) maybe the driver
doesn't belong upstream.