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: <20191209161835.7c455fc0@cakuba.netronome.com>
Date:   Mon, 9 Dec 2019 16:18:35 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Maciej Żenczykowski <zenczykowski@...il.com>
Cc:     "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 Tue, 10 Dec 2019 01:02:08 +0100, Maciej Żenczykowski wrote:
> > Could you elaborate what protocols and products are in need of this
> > functionality?  
> 
> The ones I'm aware of are:
> (a) Google's servers
> (b) Android on at least some chipsets (Qualcomm at the bare minimum,
> but I think it's pretty standard a solution) where there's a complex
> port sharing scheme between the Linux kernel on the Application
> Processor and the Firmware running on the modem (for ipv4 we only get
> one ip address from the cellular carrier).  It's basically required
> for things like wifi calling to work.

Okay, that's what I was suspecting.  It'd be great if the real
motivation for a patch was spelled out in the commit message :/

So some SoCs which run non-vanilla kernels require hacks to steal
ports from the networking stack for use by proprietary firmware.

I don't see how merging this patch benefits the community.

> > Why can't the NIC just get its own IP like it usually does with NCSI?  
> 
> Because often these nics are deployed as in place upgrades in
> environments where there's a limited number of IPs.
> Say a rack with a /27 ipv4 subnet (2**5 = 32 -> 29 usable ips, since
> network/broadcast/gateway are burned) and 15+ pre-existing machines.
> This means there's not enough IPs to assign separate ones for the nics.
> Renumbering the rack, would imply renumbering the datacenter, etc...
> And ipv4 - even RFC1918 - has long run out - so even in new
> deployments there's not enough IPv4 ips to give to nics, and IPv6
> isn't yet deployed *everywhere*.

So the conditions for this are:
 - in-place upgrade of an existing rack
 - IPv4 only
 - the existing servers didn't have NCSI or otherwise IPs for OOB
   control

Unlike the AP one this sounds like a very rare scenario..