netdev - Re: [RFC PATCH net-next] ipmr: ip6mr: APIs to support adding more than MAXVIFS/MAXMIFS

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 19 Sep 2021 03:07:34 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next] ipmr: ip6mr: APIs to support adding more
 than MAXVIFS/MAXMIFS

On Fri, Sep 17, 2021 at 06:41:23PM -0400, Stephen Suryaputra wrote:
> MAXVIFS and MAXMIFS are too small (32) for certain applications. But
> they are defined in user header files  So, use a different definition
> CONFIG_IP_MROUTE_EXT_MAXVIFS that is configurable and different ioctl
> requests (MRT_xyz_EXT and MRT6_xyz_EXT) as well as a different structure
> for adding MFC (mfcctl_ext).
> 
> CONFIG_IP_MROUTE_EXT_MAXVIFS is bounded by the IF_SETSIZE (256) in
> mroute6.h.
> 
> This patch is extending the following RFC:
> http://patchwork.ozlabs.org/project/netdev/patch/m1eiis8uc6.fsf@fess.ebiederm.org/

Quoting the above URL:

> My goal is an API that works with just a recompile of existing
> applications, and an ABI that continues to work for old applications.

Does this really work? Does the distribution version of mrouted use
the kernel UAPI headers of the running kernel? Can i upgrade to a
newer kernel, with newer headers, and it automagically pulls in a new
mrouted built using the new kernel headers? I think not. ethtool has
its own copy of the kernel headers. mrouted uses
/usr/include/linux/mroute.h which is provided by
linux-libc-dev:amd64. That is not tied to the running kernel. What
about quagga?

So in effect, you have to ask the running kernel, what value is it
using for MAXVIFS? Which means it is much more than just a recompile.
So i doubt think you can achieve this goal.

Given that, i really think you should spend the time to do a proper
solution. Add a netlink based API, which does not have the 32 limit.
Make the kernel implementation be based on a linked list. Have the
ioctl interface simply return the first 32 entries and ignore anything
above that.

      Andrew