netdev - Re: [PATCH net-next v1 3/3] net/mlx4_en: Set number of rx/tx channels using ethtool

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: <1354378718.7995.32.camel@deadeye.wl.decadent.org.uk>
Date:	Sat, 1 Dec 2012 16:18:38 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Or Gerlitz <or.gerlitz@...il.com>
CC:	Amir Vadai <amirv@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Oren Duer <oren@...lanox.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v1 3/3] net/mlx4_en: Set number of rx/tx
 channels using ethtool

On Sat, 2012-12-01 at 17:50 +0200, Or Gerlitz wrote:
> On Sat, Dec 1, 2012 at 1:58 AM, Ben Hutchings <bhutchings@...arflare.com> wrote:
> >
> > On Thu, 2012-11-29 at 21:21 +0200, Amir Vadai wrote:
> > > Add support to changing number of rx/tx channels using
> > > ethtool ('ethtool -[lL]'). Where the number of tx channels specified in
> > > ethtool
> > > is the number of rings per user priority - not total number of tx rings.
> > >
> > > Signed-off-by: Amir Vadai <amirv@...lanox.com>
> > > ---
> > >  drivers/net/ethernet/mellanox/mlx4/en_ethtool.c |   69
> > > +++++++++++++++++++++++
> > >  drivers/net/ethernet/mellanox/mlx4/en_main.c    |    2 +-
> > >  drivers/net/ethernet/mellanox/mlx4/en_netdev.c  |   26 +++++----
> > >  drivers/net/ethernet/mellanox/mlx4/en_tx.c      |    2 +-
> > >  drivers/net/ethernet/mellanox/mlx4/mlx4_en.h    |    8 ++-
> > >  5 files changed, 93 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> > > b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> > > index dc8ccb4..681bc1b 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> > > +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> > > @@ -999,6 +999,73 @@ static int mlx4_en_set_rxnfc(struct net_device
> > > *dev, struct ethtool_rxnfc *cmd)
> > [...]
> > > +static int mlx4_en_set_channels(struct net_device *dev,
> > > +             struct ethtool_channels *channel)
> > > +{
> > > +     struct mlx4_en_priv *priv = netdev_priv(dev);
> > > +     struct mlx4_en_dev *mdev = priv->mdev;
> > > +     int port_up;
> > > +     int err = 0;
> > > +
> > > +     if (channel->other_count || channel->combined_count ||
> > > +         channel->tx_count > channel->max_tx ||
> > > +         channel->rx_count > channel->max_rx ||
> >
> > The values of max_tx and max_rx are passed in from userland, so you
> > can't trust them.
> 
> Is this a general statement re ethtool values passed from user space
> or something specific here?

General statement.

> can't one assume that the ethtool process
> runs under the appropriate admin permission?

It has CAP_NET_ADMIN, which  is not the same thing as CAP_SYS_ADMIN (and
even that doesn't necessarily mean ultimate trust).

Ben.

> >> +         !channel->tx_count || !channel->rx_count)
> >> +             return -EINVAL;
> > [...]

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html