netdev - Re: Question on ethtool strategy wrt legacy ioctl

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]

Message-ID: <20240216115921.incijidup6rpeyre@lion.mk-sys.cz>
Date: Fri, 16 Feb 2024 12:59:21 +0100
From: Michal Kubecek <mkubecek@...e.cz>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Andrew Lunn <andrew@...n.ch>,
	Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: Question on ethtool strategy wrt legacy ioctl

On Fri, Feb 16, 2024 at 11:53:26AM +0100, Heiner Kallweit wrote:
> When working on ethtool functionality on both sides, userspace and
> kernel, the following questions came to my mind:
> 
> - Is there any good reason why somebody would set CONFIG_ETHTOOL_NETLINK = n ?
>   Or can this config option be removed?

I can imagine systems where there is no use for ethtool interface as
such so it IMHO makes sense to make the whole interface optional.
Originally I wanted to do this when the netlink interface was introduced
but it would require some changes outside the netlink code (there are
some hardwired calls into ethtool code in parts of kernel where you
wouldn't exactly expect them) so it fell into the "one day" category.
It would be nice to make the ioctl part optional but until netlink
supports all features provided by ioctl, it would make little practical
sense.

> - If for a certain ethtool functionality ioctl and netlink is
> supported, can the ioctl part be removed more sooner than later? Or is
> there any scenario where netlink can't be used?
> 
> - Do we have to support the case that a user wants to use an old
> ethtool w/o netlink support with a new kernel? Or is it acceptable to
> urge such users to upgrade their userspace ethtool?

We probably could if ethtool were the only userspace utility using the
interface which is not the case. There are other pieces of software
using it, some known (I'm sure wicked does and I assume so does
NetworkManager) but also some unknown and perhaps some which are not
public at all.

One of the reasons why I believe there are privately developed utilities
used only within certain environments is that while inspecting the
interface, I realized that for some parts of the ioctl interface, there
were few years between introducing the kernel side and the ethtool side
- which only makes sense if those who introduced it needed the interface
for their own software and didn't actually care about ethtool support.
And IIRC there is already a feature in the netlink interface which still
lacks the ethtool counterpart.

So I'm afraid removing ioctl support for parts of the interface that are
fully supported via netlink would be seen as "breaking the userspace".

>   Remark: I see there's certain functionality which is supported via
>   netlink only and doesn't have an ioctl fallback.

Yes, the general policy is that no new features should be added to the
ioctl interface, with the exception of trivial extensions like support
for new link modes.

Michal

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)