netdev - Re: [PATCH net-next v3 0/2] Add IP_LOCAL_PORT

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

Message-ID: <87cz78xczp.fsf@cloudflare.com>
Date:   Sat, 21 Jan 2023 13:45:50 +0100
From:   Jakub Sitnicki <jakub@...udflare.com>
To:     Neal Cardwell <ncardwell@...gle.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Kuniyuki Iwashima <kuniyu@...zon.com>, selinux@...r.kernel.org,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>, kernel-team@...udflare.com
Subject: Re: [PATCH net-next v3 0/2] Add IP_LOCAL_PORT_RANGE socket option

On Fri, Jan 20, 2023 at 11:44 AM -05, Neal Cardwell wrote:
> )On Fri, Jan 20, 2023 at 6:53 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>>
>> This patch set is a follow up to the "How to share IPv4 addresses by
>> partitioning the port space" talk given at LPC 2022 [1].
>>
>> Please see patch #1 for the motivation & the use case description.
>> Patch #2 adds tests exercising the new option in various scenarios.
>>
>> Documentation
>> -------------
>>
>> Proposed update to the ip(7) man-page:
>>
>>        IP_LOCAL_PORT_RANGE (since Linux X.Y)
>>               Set or get the per-socket default local port range. This
>>               option  can  be used to clamp down the global local port
>>               range, defined by the ip_local_port_range  /proc  inter‐
>>               face described below, for a given socket.
>>
>>               The option takes an uint32_t value with the high 16 bits
>>               set to the upper range bound, and the low 16 bits set to
>>               the lower range bound. Range bounds are inclusive.
>
> IMHO it would be nice for this text to document whether the port
> numbers are in host order or network order, and perhaps whether "high"
> and "low" here refer to host or network order. Key parts of the
> sockets API express port numbers in network order, but this new API
> seems to express port numbers in host order, so it seem worth (a)
> deciding carefully, and (b) documenting explicitly in the man page
> text (here in the cover letter) and commit message for the patch
> (patch #1).

Good point. Thanks for feedback.

I will expand the description for the man page and the patch #1.

Personally I don't see any upside to using the network byte order here.
With host byte order, users don't need to do anything else but pack the
two u16 values.