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:   Tue, 8 Feb 2022 13:30:32 +0000
From:   "Drewek, Wojciech" <wojciech.drewek@...el.com>
To:     Harald Welte <laforge@...ocom.org>,
        Marcin Szycik <marcin.szycik@...ux.intel.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "michal.swiatkowski@...ux.intel.com" 
        <michal.swiatkowski@...ux.intel.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "osmocom-net-gprs@...ts.osmocom.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

Thanks for the response.

> -----Original Message-----
> From: Harald Welte <laforge@...ocom.org>
> Sent: sobota, 5 lutego 2022 17:34
> To: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Cc: netdev@...r.kernel.org; michal.swiatkowski@...ux.intel.com; Drewek, Wojciech <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 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.
For now we don't have such tree. I will see what we can do.

> 
> 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.
Sure, I'll add such comment.

> 
> > 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.
I agree, it would look cleaner.

> 
> > 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.
Yes, it is possible to create socket with any port number using FD approach,
but gtp module still assumes that ports are 2152 and 3386 at least in tx path
(see gtp_push_header).  Implementing this shouldn't be hard but is it crucial?

> 
> --
> - Harald Welte <laforge@...ocom.org>            http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)