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
| ||
|
Date: Mon, 13 Mar 2017 23:26:55 -0400 From: Jarod Wilson <jarod@...hat.com> To: Jay Vosburgh <jay.vosburgh@...onical.com> Cc: netdev <netdev@...r.kernel.org> Subject: Re: bond procfs hw addr prints On 2017-03-13 10:06 PM, Jarod Wilson wrote: > On 2017-03-13 8:28 PM, Jay Vosburgh wrote: >> Jarod Wilson <jarod@...hat.com> wrote: >> >>> I've got a bug report for someone using a Intel OPA devices in a >>> bond, and >>> it appears these devices have a hardware address length of 20, >>> opposed to >>> the typical 6 on ethernet. When they dump /proc/net/bonding/bondX, it >>> only >>> prints the first 6 of the address, per %pM and mac_address_string(), >>> while >>> sysfs for the interface does print the right thing, since it uses >>> sysfs_print_mac(), which takes a length argument. >> >> This (20 octet MAC length) is true for any Infiniband device. >> >>> So the question is... What's the best route to take here? Expand %pM to >>> support variable length hardware addresses? Use sysfs_* in procfs? >>> Reinvent the wheel? Nothing I've tinkered with just yet feels very >>> clean, >>> on top of not actually working yet. :) >> >> sysfs_format_mac (not _print_mac) uses "%*phC", len, addr in its >> format string. Perhaps that format would be a better choice than %pM >> for this case? > > Ah, I'd failed to fully grasp how %phC worked, had actually tried it w/o > the * in there, and only the first char of the addr was printing. > Working on an updated version that uses %*phC properly, which does look > like the way to go here. (Didn't help that I was also looking at an > older codebase that didn't have the sysfs_format_mac de-duplication). > I'll try to have a tested patch in flight tomorrow. Hm... One problem I'm seeing: perm_hwaddr[ETH_ALEN], partner_system[ETH_ALEN], mac_addr_value[ETH_ALEN]. Looks like just about all places where storage for only ETH_ALEN is available needs to be adjusted to maybe MAX_ADDR_LEN? So I have something tested that uses %*phC, but only on ethernet hardware so far, and I forsee bad juju for infiniband, because of that ETH_ALEN issue... -- Jarod Wilson jarod@...hat.com
Powered by blists - more mailing lists