netdev - Re: [PATCH net-next v3] net-loopback: set lo dev initial state to UP

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]

Message-ID: <87czx978x8.fsf@nvidia.com>
Date:   Tue, 9 Feb 2021 12:54:59 +0100
From:   Petr Machata <petrm@...dia.com>
To:     Jian Yang <jianyang.kernel@...il.com>
CC:     <davem@...emloft.net>, <kuba@...nel.org>, <netdev@...r.kernel.org>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Jian Yang <jianyang@...gle.com>
Subject: Re: [PATCH net-next v3] net-loopback: set lo dev initial state to UP


Jian Yang <jianyang.kernel@...il.com> writes:

> From: Jian Yang <jianyang@...gle.com>
>
> Traditionally loopback devices come up with initial state as DOWN for
> any new network-namespace. This would mean that anyone needing this
> device would have to bring this UP by issuing something like 'ip link
> set lo up'. This can be avoided if the initial state is set as UP.

This will break user scripts, and it fact breaks kernel's very own
selftest. We currently have this internally:

    diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
    index 4c7d33618437..bf8ed24ab3ba 100755
    --- a/tools/testing/selftests/net/fib_nexthops.sh
    +++ b/tools/testing/selftests/net/fib_nexthops.sh
    @@ -121,8 +121,6 @@ create_ns()
     	set -e
     	ip netns add ${n}
     	ip netns set ${n} $((nsid++))
    -	ip -netns ${n} addr add 127.0.0.1/8 dev lo
    -	ip -netns ${n} link set lo up

     	ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
     	ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
    -- 
    2.26.2

This now fails because the ip commands are run within a "set -e" block,
and kernel rejects addition of a duplicate address.