netdev - Re: [Linux-v4.4-LTS] ppp: Backport of rtnetlink device handling

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]

Date:	Fri, 8 Jan 2016 12:54:35 +0100
From:	Guillaume Nault <g.nault@...halink.fr>
To:	Sedat Dilek <sedat.dilek@...il.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [Linux-v4.4-LTS] ppp: Backport of rtnetlink device handling

On Fri, Jan 08, 2016 at 10:28:39AM +0100, Sedat Dilek wrote:
> On Mon, Jan 4, 2016 at 1:55 PM, Guillaume Nault <g.nault@...halink.fr> wrote:
> > On Mon, Jan 04, 2016 at 08:47:30AM +0100, Sedat Dilek wrote:
> >> Hi Guillaume,
> >>
> >> which patches do I need to backport "ppp: rtnetlink device handling"
> >> to Linux v4.4 which will be a LongTerm-Supported (LTS) Linux-kernel
> >> [0]?
> >>
> > Quite frankly, backporting this series doesn't look like a good idea.
> > It only provides a new ABI for creating ppp devices and your control
> > plane most likely hasn't been updated to use it. So it won't bring any
> > benefit.
> >
> 
> What do you mean by "control plane"?
> 
For the purpose of this discussion, I mean the PPP daemon running in
user space (programs like pppd or accel-ppp).

They implement control protocols like LCP, authentication and various
NCPs, used to negociate PPP encapsulation parameters. They also have to
report on these parameters to the kernel, so that it can properly
handle data exchanged over the established PPP connections. This
generally includes creating a ppp device.

My patch set allows user space to create ppp devices using rtnetlink,
which is more flexible than the current PPP specific ioctl(). But the
PPP daemon needs to be updated or it won't know about the new rtnetlink
and will continue to use the ioctl (which is fine as long as the added
features brought by rtnetlink aren't necessary). That's why I wonder
why do you want to backport this series. I brings no value if user
space isn't able to take advantage of PPP's rtnetlink API.

FYI, the plan is to use the rtnl interface to handle things like
network isolation (with network namespaces) and deterministic ppp
device names in accel-ppp.

> Does anything speak against to have these patches for upcoming Linux v4.5?
> AFAICS, the merge-window will open next week.
> 
The patch set has been deferred due to lack of external reviews. I'll
repost after the merge window, so that interested people will have
enough time to comment on it. Therefore it won't be in v4.5. If
everything goes fine with the new submission, it could go into v4.6.