Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Tue, 10 Oct 2023 14:20:51 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Justin Stitt <justinstitt@google.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
        Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH] net: dsa: vsc73xx: replace deprecated strncpy with
 ethtool_sprintf
Message-ID: <20231010112051.zgefbx2c3tjneudz@skbuf>
References: <20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com>
 <20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com>
 <20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com>
Precedence: bulk

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@vger.kernel.org
> Signed-off-by: Justin Stitt <justinstitt@google.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.

>  	}
>  
>  	/* 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@google.com>
>