netdev - Re: [RFC PATCH net-next v3 1/5] gtp: Allow to create GTP device without FDs

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]

Date:   Wed, 9 Feb 2022 19:04:01 +0100
From:   Marcin Szycik <marcin.szycik@...ux.intel.com>
To:     Harald Welte <laforge@...ocom.org>
Cc:     netdev@...r.kernel.org, michal.swiatkowski@...ux.intel.com,
        wojciech.drewek@...el.com, davem@...emloft.net, kuba@...nel.org,
        pablo@...filter.org, osmocom-net-gprs@...ts.osmocom.org
Subject: Re: [RFC PATCH net-next v3 1/5] gtp: Allow to create GTP device
 without FDs

Hi Harald,

Sorry for long delay in reply.

On 05-Feb-22 17:34, Harald Welte wrote:
> Hi Marcin, Wojciech,
> 
> thanks for the revised patch. In general it looks fine to me.
> 
> Do you have a public git tree with your patchset applied?  I'm asking as
> we do have automatic testing in place at https://jenkins.osmocom.org/ where I
> just need to specify a remote git repo andit will build this kernel and
> run the test suite.

I've created a public fork with our patchset applied, please see [1].

> 
> Some minor remarks below, all not critical, just some thoughts.
> 
> It might make sense to mention in the commit log that this patch by itself
> would create GTP-U without GTP ECHO capabilities, and that a subsequent
> patch will address this.
> 
>> This patch allows to create GTP device without providing
>> IFLA_GTP_FD0 and IFLA_GTP_FD1 arguments. If the user does not
>> provide file handles to the sockets, then GTP module takes care
>> of creating UDP sockets by itself. 
> 
> I'm wondering if we should make this more explicit, i.e. rather than
> implicitly creating the kernel socket automagically, make this mode
> explicit upon request by some netlink attribute.
> 
>> Sockets are created with the
>> commonly known UDP ports used for GTP protocol (GTP0_PORT and
>> GTP1U_PORT).
> 
> I'm wondering if there are use cases that need to operate on
> non-standard ports.  The current module can be used that way (as the
> socket is created in user space). If the "kernel socket mode" was
> requested explicitly via netlink attribute, one could just as well
> pass along the port number[s] this way.
> 

[1] https://github.com/mszycik/linux/tree/cpk_switchdev_gtp