| Message ID | 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | net: dsa: vsc73xx: replace deprecated strncpy with ethtool_sprintf | expand |
On 10/9/23 15:54, 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> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
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> >
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.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@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. 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@google.com> > > > Thanks Justin
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.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@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"? Because it's a string literal, no warning there. Maybe an argument regarding style could be made. I have no style preference here so I could send v2 if you feel strongly about it. > > > > > /* 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> > > > Thanks Justin
On Tue, Oct 10, 2023 at 02:49:26PM -0700, Justin Stitt wrote: > On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > Here you don't use "%s", but everywhere else you do. Can't you just pass > > the counter name everywhere, without "%s"? > > Because it's a string literal, no warning there. Maybe an argument > regarding style could be made. I have no style preference here > so I could send v2 if you feel strongly about it. No, leave it alone here, don't add the "%s" where it's not needed. But I guess you'll have to send a v2 anyway due to the other comment.
On Tue, Oct 10, 2023 at 10:44:42AM -0700, Justin Stitt wrote: > 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 : ""); > } Looks like that would address my comment, and it looks okay.
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"); /* 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); } /* 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); } }
`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(-) --- base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b Best regards, -- Justin Stitt <justinstitt@google.com>