netdev - Re: contributions to iproute2 (resend with patches fixed)

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>] [day] [month] [year] [list]

Message-ID: <550CF25B.4080708@dogpad.tk>
Date:	Fri, 20 Mar 2015 23:23:55 -0500
From:	Joe Harvell <jharvell@...pad.tk>
To:	netdev@...r.kernel.org
CC:	Stephen Hemminger <shemming@...cade.com>
Subject: Re: contributions to iproute2 (resend with patches fixed)

Sorry I should have proof-read this before sending.  The patches in the
previous email were reversed.  These are correct.
------------------------------------------------------------------------

Thanks, Stephen.

The bugfix is attached as fix-broken-get_prefix_1.diff with the 
following commit log:

commit 415464c94a62cfaa9c5ba493e45ce24a58d2118a
Author: Joe Harvell <joe.harvell@...comms.com>
Date:   Fri Mar 20 15:08:51 2015 -0500

       Fixing obvious error of passing in the wrong variable for the 
family parameter
       of af_bit_len.

I assume master must have some new change because this fix was needed 
for a basic 'ip addr add 10.0.3.1/24 dev dumbo label foo' command I 
pased in.  In this case, 'family' passed into get_addr_1 two lines above 
is zero, causing get_addr_1 to detect the family from the address and 
populate the result in the family field in dst.  But then instead of 
passing in the result, family (still 0) is passed in to af_bit_len. 
Without my change, the above command complains that 10.0.3.1/24 is not 
an address prefix.  With the change it works fine as expected.

The enhancement is attached as addr-label-noncompat.diff with the 
following commit log which speaks for itself.

commit 51b21cc0382e8a99246289a13e6e842f10e23c80
Author: Joe Harvell <joe.harvell@...comms.com>
Date:   Fri Mar 20 15:02:16 2015 -0500

       Making -force option of ip command also allow address labels that 
are not
       backward-compatible with ifconfig.  Note that even without this 
change
       the ip command does allow some incompatible address labels to be 
created.
       ifconfig depends on the labels beginning with 
<interface-name><colon>, but
       the ip command (even before the changes in this commit) only 
requires the
       prefix of the label to be <interface-name>.  Thus, if you add a 
label such
       as eth0-media, it will be accepted by ip but ifconfig will barf 
on ifconfig -a.
       The motivation for this change is that the lenght allowed for a 
lable is small,
       so requiring a long prefix for ifconfig backwards compatibility 
limits the
       usefulness of the label.  For embedded systems (or any system) 
where ifconfig
       is not even installed, it is useful to be able to create longer 
labels.

The only thing I have to add to the above is that maybe also the 
existing check (when -force is not specified) should be strengthened to 
reject any labels not beginning with <interface-name><colon> instead of 
just <interface-name>.  Try the following command sequence to the 
existing code to see what I mean:

sudo ip link add name dumbo type dummy
sudo ip addr add 10.0.1.0/24 dev dumbo label dumbo-a
ifconfig -a

You will see ifconfig abort when it encouters the address label dumo-a 
that it cannot map back to an interface.  I think the intent of the 
existing check is to prevent people from inadvertently creating such a 
configuration.  I think -force is a good option to enable it since 
anyone enabling this option must realize it and are not doing it 
inadvertently.

Thanks for your consideration.
---
Joe Harvell

On 20/03/2015 16:08, Stephen Hemminger wrote:
> On Fri, 20 Mar 2015 20:17:26 +0000
> Joe Harvell <jharvell@...pad.tk> wrote:
>
>> Hi Stephen,
>>
>> I have an obvious bugfix and small enhancement to the ip command.  I
>> have each implemented in a separate branch baselined from today's master
>> (git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git)
>> and would like to submit the changes for consideration to be merged to
>> master.  I cannot push these branches, so what is the procedure?
>>
>> Thanks.
>>
>> ---
>> Joe Harvell
>>
> Send patch to netdev@...r.kernel.org
> It will get reviewed there and I will track it in patchwork

View attachment "fix-broken-get_prefix_1.diff" of type "text/plain" (377 bytes)

View attachment "addr-label-noncompat.diff" of type "text/plain" (1850 bytes)