netdev - 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-next>] [day] [month] [year] [list]

Message-Id: <C42DZQLTPHM5.2THDSRK84BI3T@wkz-x280>
Date:   Thu, 09 Jul 2020 22:47:54 +0200
From:   "Tobias Waldekranz" <tobias@...dekranz.com>
To:     <netdev@...r.kernel.org>
Cc:     <andrew@...n.ch>, <f.fainelli@...il.com>, <hkallweit1@...il.com>
Subject: MDIO Debug Interface

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. The closest thing I've found are the
SIOCG/SMIIREG ioctls, but they have several drawbacks:

1. "Write register" is not always exactly that. The kernel will try to
   be extra helpful and do things behind the scenes if it detects a
   write to the reset bit of a PHY for example.

2. Only one op per syscall. This means that is impossible to implement
   many operations in a safe manner. Something as simple as a
   read/mask/write cycle can race against an in-kernel driver.

3. Addressing is awkward since you don't address the MDIO bus
   directly, rather "the MDIO bus to which this netdev's PHY is
   connected". This makes it hard to talk to devices on buses to which
   no PHYs are connected, the typical case being Ethernet switches.

The kernel side of mdio-tools, mdio-netlink, tries to address these
problems by adding a GENL interface with which a user can interact
with an MDIO bus directly.

The user sends a program that the mdio-netlink module executes,
possibly emitting data back to the user. I.e. it implements a very
simple VM. Read/mask/write operations could be implemented by
dedicated commands, but when you start looking at more advanced things
like reading out the VLAN database of a switch you need to state and
branching.

FAQ:

- A VM just for MDIO, that seems ridiculous, no?

  It does. But if you want to support the complex kinds of operations
  that I'm looking for, without the kernel module having to be aware
  of every kind of MDIO device in the world, I haven't found an easier
  way.

- Why not use BPF?

  That could absolutely be one way forward, but the GENL approach was
  easy to build out-of-tree to prove the idea. Its not obvious how it
  would work though as BPF programs typically run async on some event
  (probe hit, packet received etc.) whereas this is a single execution
  on behalf of a user. So to what would the program be attached? The
  output path is also not straight forward, but it could be done with
  perf events i suppose.

My question is thus; do you think mdio-netlink, or something like it,
is a candidate for mainline?

Thank you