netdev - Re: [PATCH v2] net: introduce ip_local_unbindable

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: <CAKD1Yr05=sRDTefSP6bmb-VvvDLe9=xUtAF0q3+rn8=U9UjPcA@mail.gmail.com>
Date:   Fri, 13 Dec 2019 09:16:03 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Maciej Żenczykowski <zenczykowski@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Linux Network Development Mailing List 
        <netdev@...r.kernel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Sean Tranchetti <stranche@...eaurora.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Linux SCTP <linux-sctp@...r.kernel.org>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Subject: Re: [PATCH v2] net: introduce ip_local_unbindable_ports sysctl

On Wed, Dec 11, 2019 at 2:31 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
> I don't consider users of non-vanilla kernels to necessarily be a
> reason to merge patches upstream, no. They carry literally millions
> of lines of patches out of tree, let them carry this patch, too.
> If I can't boot a vanilla kernel on those devices, and clearly there is
> no intent by the device manufacturers for me to ever will, why would I
> care?

That's *not* the intent.
https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/

> > The reason Android runs non-vanilla kernels is *because* patches like
> > this - that make Linux work in the real world - are missing from
> > vanilla Linux

That's exactly the point here. Saying, "Android will never use
mainline, so why should mainline take their patches" is a
self-fulfilling prophecy. Obviously, if mainline never takes Android
patches, then yes, Android will never be able to use mainline. We do
have an Android tree we can take this patch into. But we don't want to
take it without at least attempting to get it into mainline first.

The use case here is pretty simple. There are many CPUs in a mobile
phone. The baseband processor ("modem") implements much of the
functionality required by cellular networks, so if you want cellular
voice or data, it needs to be able to talk to the network. For many
reasons (architectural, power conservation, security), the modem needs
to be able to talk directly to the cellular network. This includes,
for example, SIP/RTP media streams that go directly to the audio
hardware, IKE traffic that is sent directly by the modem because only
the modem has the keys, etc. Normally this happens directly on the
cellular interface and Linux/Android is unaware of it. But, when using
wifi calling (which is an IPsec tunnel over wifi to an endpoint inside
the cellular network), the device only has one IPv4 address, and the
baseband processor and the application processor (the CPU that runs
Linux/Android) have to share it. This means that some ports have to be
reserved so that the baseband processor can depend on using them. NAT
cannot be used because the 3GPP standards require protocols that are
not very NAT-friendly, and because the modem needs to be able to
accept unsolicited inbound traffic.

Other than "commit message doesn't have a use case", are there
technical concerns with this patch?