Re: [PATCH] igb: Add MII write support

[Andrew Lunn]

On Wed, Jun 05, 2024 at 01:51:24PM -0700, Jacob Keller wrote:
> 
> 
> On 6/3/2024 8:10 PM, jackie.jone@xxxxxxxxxxxxxxxxxxx wrote:
> > From: Jackie Jone <jackie.jone@xxxxxxxxxxxxxxxxxxx>
> > 
> > To facilitate running PHY parametric tests, add support for the SIOCSMIIREG
> > ioctl. This allows a userspace application to write to the PHY registers
> > to enable the test modes.
> > 
> > Signed-off-by: Jackie Jone <jackie.jone@xxxxxxxxxxxxxxxxxxx>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> > index 03a4da6a1447..7fbfcf01fbf9 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -8977,6 +8977,10 @@ static int igb_mii_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
> >  			return -EIO;
> >  		break;
> >  	case SIOCSMIIREG:
> > +		if (igb_write_phy_reg(&adapter->hw, data->reg_num & 0x1F,
> > +				     data->val_in))
> > +			return -EIO;
> > +		break;
> 
> A handful of drivers seem to expose this. What are the consequences of
> exposing this ioctl? What can user space do with it?

User space can break the PHY configuration, cause the link to fail,
all behind the MAC drivers back. The generic version of this call
tries to see what registers are being written, and update state:

https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L325

But you can still break it.

> It looks like a few drivers also check something like CAP_NET_ADMIN to
> avoid allowing write access to all users. Is that enforced somewhere else?

Only root is allowed to use it. So it is a classic 'You have the
option to shoot yourself in the foot'.

For the use case being talked about here, there has been a few emails
one the list about implementing the IEEE 802.3 test modes. But nobody
has actually got around to doing it. Not that it would help in this
case, Intel don't use the Linux PHY drivers, which is where i would
expect to see such code implemented first. Maybe if the "Great Intel
Ethernet driver refactoring" makes progress, it could swap to using
the Linux PHY drivers.

      Andrew