Message-ID: <CAFhGd8pF04DCbMJFOR+93azqzWYZ2aE9FByp7yVVJR90g7MN9g@mail.gmail.com>
Date: Tue, 10 Oct 2023 10:44:42 -0700
From: Justin Stitt <justinstitt@...gle.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, 
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] net: dsa: vsc73xx: replace deprecated strncpy with ethtool_sprintf

On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> On Mon, Oct 09, 2023 at 10:54:37PM +0000, Justin Stitt wrote:
> > `strncpy` is deprecated for use on NUL-terminated destination strings
> > [1] and as such we should prefer more robust and less ambiguous string
> > interfaces.
> >
> > ethtool_sprintf() is designed specifically for get_strings() usage.
> > Let's replace strncpy in favor of this more robust and easier to
> > understand interface.
> >
> > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
> > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
> > Link: https://github.com/KSPP/linux/issues/90
> > Cc: linux-hardening@...r.kernel.org
> > Signed-off-by: Justin Stitt <justinstitt@...gle.com>
> > ---
> > Note: build-tested only.
> > ---
> >  drivers/net/dsa/vitesse-vsc73xx-core.c | 20 ++++++--------------
> >  1 file changed, 6 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c b/drivers/net/dsa/vitesse-vsc73xx-core.c
> > index 4f09e7438f3b..09955fdea2ff 100644
> > --- a/drivers/net/dsa/vitesse-vsc73xx-core.c
> > +++ b/drivers/net/dsa/vitesse-vsc73xx-core.c
> > @@ -928,7 +928,8 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset,
> >       const struct vsc73xx_counter *cnt;
> >       struct vsc73xx *vsc = ds->priv;
> >       u8 indices[6];
> > -     int i, j;
> > +     u8 *buf = data;
> > +     int i;
> >       u32 val;
> >       int ret;
> >
> > @@ -948,10 +949,7 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset,
> >       indices[5] = ((val >> 26) & 0x1f); /* TX counter 2 */
> >
> >       /* The first counters is the RX octets */
> > -     j = 0;
> > -     strncpy(data + j * ETH_GSTRING_LEN,
> > -             "RxEtherStatsOctets", ETH_GSTRING_LEN);
> > -     j++;
> > +     ethtool_sprintf(&buf, "RxEtherStatsOctets");
>
> Here you don't use "%s", but everywhere else you do. Can't you just pass
> the counter name everywhere, without "%s"?
>
> >
> >       /* Each port supports recording 3 RX counters and 3 TX counters,
> >        * figure out what counters we use in this set-up and return the
> > @@ -962,22 +960,16 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset,
> >       for (i = 0; i < 3; i++) {
> >               cnt = vsc73xx_find_counter(vsc, indices[i], false);
> >               if (cnt)
> > -                     strncpy(data + j * ETH_GSTRING_LEN,
> > -                             cnt->name, ETH_GSTRING_LEN);
> > -             j++;
> > +                     ethtool_sprintf(&buf, "%s", cnt->name);
>
> The code conversion is not functionally identical, and I think it's a
> bit hard to make it identical.
>
> The VSC7395 has 45 port counters, but it seems that it can only monitor
> and display 8 of them at a time - 2 fixed and 6 configurable through
> some windows.
>
> vsc73xx_get_strings() detects which counter is each window configured
> for, based on the value of the CNT_CTRL_CFG hardware register (VSC73XX_C_CFG
> in the code). It displays a different string depending on the hardware
> value.
>
> The code must deal with the case where vsc73xx_find_counter() returns
> NULL, aka the hardware window is configured for a value that vsc73xx_tx_counters[]
> and vsc73xx_rx_counters[] don't know about.
>
> Currently, the way that this is treated is by skipping the strncpy()
> (and thus leaving an empty string), and incrementing j to get to the
> next ethtool counter, and next window.
>
> The order of the strings in vsc73xx_get_strings() needs to be strongly
> correlated to the order of the counters from vsc73xx_get_ethtool_stats().
> So, the driver would still print counter values for the unknown windows,
> it will just not provide a string for them.
>
> In your proposal, the increment of j basically goes into the "if (cnt)"
> block because it's embedded within ethtool_sprintf(), which means that
> if a hardware counter is unknown, the total number of reported strings
> will be less than 8. Which is very problematic, because vsc73xx_get_sset_count()
> says that 8 strings are reported. Also, all the counter strings after
> the unknown one will be shifted to the left.
>
> I suggest that "if (!cnt)", you should call ethtool_sprintf() with an
> empty string, to preserve the original behavior.

Wow, thanks for the feedback here. I agree that the current
proposal is problematic. I wonder what you think about
using a ternary to avoid smelly code dupe:

for (i = 0; i < 3; i++) {
        cnt = vsc73xx_find_counter(vsc, indices[i], false);
        ethtool_sprintf(&buf, "%s", cnt ? cnt->name : "");
}

>
> >       }
> >
> >       /* TX stats begins with the number of TX octets */
> > -     strncpy(data + j * ETH_GSTRING_LEN,
> > -             "TxEtherStatsOctets", ETH_GSTRING_LEN);
> > -     j++;
> > +     ethtool_sprintf(&buf, "TxEtherStatsOctets");
> >
> >       for (i = 3; i < 6; i++) {
> >               cnt = vsc73xx_find_counter(vsc, indices[i], true);
> >               if (cnt)
> > -                     strncpy(data + j * ETH_GSTRING_LEN,
> > -                             cnt->name, ETH_GSTRING_LEN);
> > -             j++;
> > +                     ethtool_sprintf(&buf, "%s", cnt->name);
> >       }
> >  }
> >
> >
> > ---
> > base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
> > change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b
> >
> > Best regards,
> > --
> > Justin Stitt <justinstitt@...gle.com>
> >
>

Thanks
Justin

Powered by blists - more mailing lists