netdev - Re: [PATCH 1/2] net: enable IPv6 iff IPv4

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Apr 2019 14:52:58 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Maciej Żenczykowski <zenczykowski@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] net: enable IPv6 iff IPv4

On 4/1/19 2:02 PM, Maciej Żenczykowski wrote:
>> Things are modular because we don't unilaterally make decisions for
>> people on this level.
> 
> We do unilaterally make various decisions - some of them quite big in scope.
> Although perhaps not this one.
> 
>> This is why I'm very much not too motivated to integrate changes like
>> this, even though I understand the motivation and simplifications this
>> would enable.
> 
>> I mean, who the heck are we to tell someone that because they make
>> some tiny device meant for an isolated ipv4 environment that they
>> _MUST_ have ipv6 also built into their kernels?
> 
> One of the major reasons why ipv6 is seeing such slow adoption is because
> people keep manufacturing ipv4 only devices.  It's just a stupid
> network attached
> sensor, but it doesn't work on your network because it doesn't support ipv6...
> and as a result you need to keep around legacy ipv4 support.
> 
> Why should the manufacturers be allowed to tell me how to run my network?
> 
> These small devices are unlikely to be even running a 5.2+ kernel for another
> half decade or more.
> 
> ie. we're talking about hardware that'll come to market 3-4 years from now,
> at the earliest, probably later, since no one updates the
> kernel/software on these
> devices after they initially start shipping.
> 
> If they truly need something so tiny and so ipv6 unsupporting, they
> can simply run 5.1 or older.

You can't use your own argument both ways and complain that people
design devices that are never upgraded and then just give them another
argument for not updating because IPv6 simply makes them make an
unacceptable decision which could be either of:

- creating another attack surface they had not thought about initially

- making their memory budget explode to the point where a new kernel
becomes out of the equation, period

- the product is simply not meeting the requirements of *not* supporting
IPv6 (granted it could be a stupid requirement, yet be one)

> It's not like we'll delete the source code for older versions of Linux.

No, but it is another roadblock to upstreaming changes for your embedded
device if you need to make a few tweaks here and there. And given the
direction you want to go later on, it won't be as simple as a revert of
your patches to go back to hypothetical pre-5.1 behavior.

> 
> ---
> 
> Perhaps just making ipv6 a boolean instead of a tristate would be acceptable?
> 
> That would get rid of most of the craziness with supporting loading
> ipv6 as a module,
> the checks for is this function null, etc. and we could still move all
> the fields into
> the main ip struct just surrounded by #ifdef IPV6
> 

Are you seeing a performance problem where having IPv6 be built-in and
all code being reachable would help, or are you trying to improve the
maintenance burden, or is it something else?
-- 
Florian