linux-kernel - Re: How to find out name or id of newly created interface

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:   Mon, 2 Aug 2021 19:23:46 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Guillaume Nault <gnault@...hat.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: How to find out name or id of newly created interface

On Monday 02 August 2021 15:43:20 Guillaume Nault wrote:
> On Mon, Aug 02, 2021 at 12:58:25PM +0200, Pali Rohár wrote:
> > On Monday 02 August 2021 12:02:38 Guillaume Nault wrote:
> > > 
> > > So the proper solution is to implement NLM_F_ECHO support for
> > > RTM_NEWLINK messages (RTM_NEWROUTE is an example of netlink handler
> > > that supports NLM_F_ECHO, see rtmsg_fib()).
> > 
> > Do you know if there is some workaround / other solution which can be
> > used by userspace applications now? And also with stable kernels (which
> > obviously do not receive this new NLM_F_ECHO support for RTM_NEWLINK)?
> 
> I unfortunately can't think of any clean solution. It might be possible
> to create the new interface with attributes very unlikely to be used by
> external programs and retrieve the interface name and id by monitoring
> link creation messages (like 'ip monitor' does). But at this point it's
> probably easier to just set the interface name and retry with a
> different name every time it conflicted with an existing device.

"set interface name and retry" is what I'm using now... And looks like
it is the only stable solution for now.

I was already thinking about monitoring link creation messages... if
there is not some stable message ordering (e.g. order of response and
monitor message) but I have not deduced anything from the code.

> Maybe someone else could propose less hacky solutions, but I really
> can't think of anything else apart from implementing NLM_F_ECHO.