netdev - Re: MDIO Debug 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:   Fri, 10 Jul 2020 00:39:36 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com, hkallweit1@...il.com
Subject: Re: MDIO Debug Interface

On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> Hi netdev,
> 
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
> 
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c-dev or
> spi-dev for example.

Hi Tobias

These APIs exist to allow user space drivers. I don't know how much
that happens now a days, there seems to be a lot of kernel space
drivers for SPI and I2C, but it is still possible to write user space
drivers.

We have never allowed user space drivers for MDIO devices. As a
result, we have pretty good kernel support for PHYs and quite a few L2
switches, and the numbers keep increasing.

But the API you are suggesting sounds like it becomes an easy way for
vendors to run their SDKs in user space, with a small bit of glue code
to this new API. That is something we should avoid.

It is a difficult trade off. Such an API as you suggest does allow for
nice debug tools for driver developers. And i have no problems with
such a tool existing, being out of tree for any developer to use. But
i'm not too happy with it being in mainline because i suspect it will
get abused by vendors.

Something i'm want to look at soon is dumping more of the internal
state of the mv88e6xxx switches. The full ATU and VTU, TCAM etc. I
think devlink region could work for this. And i think the ethtool -d
command could be made a lot better now we have a netlink API. The old
API assumed a single address space. It would be nice to support
multiple address spaces.

The advantage of these APIs is that they cannot be abused by vendors
to write user space drivers. But we can still have reasonably powerful
debug tools built on top of them.

       Andrew