From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 65BA542814;
Thu, 23 Mar 2023 00:43:05 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id B99864161A;
Thu, 23 Mar 2023 00:43:04 +0100 (CET)
Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com
[209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 7F88C4021E
for <dev@dpdk.org>; Thu, 23 Mar 2023 00:43:03 +0100 (CET)
Received: by mail-pj1-f50.google.com with SMTP id
lr16-20020a17090b4b9000b0023f187954acso265809pjb.2
for <dev@dpdk.org>; Wed, 22 Mar 2023 16:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1679528582;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=bm4VF47Nw5dtyFCfpckMm4MstCpVNy5LW+VRDLvBCbE=;
b=NdrdhAlrrsSPyau3BLUObpA6OPzh99d4hi/UPsnFx01326qH+DsFquMr3sz+IMre+l
p1O8XNs/O1KNJMqqZ11SywD5zJt6c38HpCCi4Q4O9kphHzGoFKKtoqCZxvmLy7GUjrhL
9a/AJny2DTyBc2O3Pofw6SMB+/WKLr49tru1/sj74Oz8nixOVuPCtzajlYBtC4KTbSPZ
cZSZPIp6n88OEi/HNCQRptncGIxZ71nTUTotQpc/EtR342GZCcM0oC/coc43W/YwyROG
upsiplWbIxoDcusXf8TNi9vK4GkpV58MQuVkz0yG3BPORhgtsCD1ef7PLyXhmhv9bJ2S
zqIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112; t=1679528582;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=bm4VF47Nw5dtyFCfpckMm4MstCpVNy5LW+VRDLvBCbE=;
b=PvLd1XF59P7ilKlw5RKnEscD4lppUBWX2j7PhXBgJf1khc8CvUQJVyKHaA7YILbPR9
M55NZPzbRfvw6HJGkpV7EEyiWSpUFC9nZPVpg1SPwepkbZzowxXVBzC1ljK4dxcesS9s
SuRCeh5DAvyjwPuKPNEO83kRS2eRQLFAErV7TYOTupz2ysZJ1/CmR0JYXn2798VSsc99
Wsl5N7jijvmXCcva+HgncnHcy0LjEQo/B96LPii2VrESld8zsvRHWGezY8atHeP71vfg
teqEDD6uRlEh1P1OZ3fVNK8nyCMqifbz+c8RDwWkA7YwujkcbotLyj0V8yWfy1mXgXFF
t47A==
X-Gm-Message-State: AO0yUKUn9/0Rrr+6wddfLRyh2SXQrofwkSh0CqVUtnFva56r1+q4e5Yo
aUvmmhHfVXK6SwOkuYvGG38WhQ==
X-Google-Smtp-Source: AK7set+FfnUpEErLDt8zOWlXQFZOl+QOjvKtdw1jLIxjXJp7j+rVK1nflqcC2lQKFmfpB72jAk1B0g==
X-Received: by 2002:a17:90b:350e:b0:23f:2c65:fab7 with SMTP id
ls14-20020a17090b350e00b0023f2c65fab7mr5362168pjb.42.1679528582328;
Wed, 22 Mar 2023 16:43:02 -0700 (PDT)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
by smtp.gmail.com with ESMTPSA id
ha2-20020a17090af3c200b00233864f21a7sm42244pjb.51.2023.03.22.16.43.01
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 22 Mar 2023 16:43:02 -0700 (PDT)
Date: Wed, 22 Mar 2023 16:43:00 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: David Christensen <drc@linux.vnet.ibm.com>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [PATCH] net/tap: resolve stringop-overflow with gcc 12 on ppc64le
Message-ID: <20230322164300.2402d9f1@hermes.local>
In-Reply-To: <20230322212439.524725-1-drc@linux.vnet.ibm.com>
References: <20230322212439.524725-1-drc@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Wed, 22 Mar 2023 17:24:39 -0400
David Christensen <drc@linux.vnet.ibm.com> wrote:
> Building DPDK with gcc 12 on a ppc64le system generates a
> stringop-overflow warning. Replace the local MAC address
> validation function parse_user_mac() with a call to
> rte_ether_unformat_addr() instead.
>
> Bugzilla ID: 1197
> Cc: stable@dpdk.org
>
> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
> ---
> drivers/net/tap/rte_eth_tap.c | 25 +------------------------
> 1 file changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 089ac202fa..1f83f49c0e 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -2267,29 +2267,6 @@ set_remote_iface(const char *key __rte_unused,
> return 0;
> }
>
> -static int parse_user_mac(struct rte_ether_addr *user_mac,
> - const char *value)
> -{
> - unsigned int index = 0;
> - char mac_temp[strlen(ETH_TAP_USR_MAC_FMT) + 1], *mac_byte = NULL;
> -
> - if (user_mac == NULL || value == NULL)
> - return 0;
> -
> - strlcpy(mac_temp, value, sizeof(mac_temp));
> - mac_byte = strtok(mac_temp, ":");
> -
> - while ((mac_byte != NULL) &&
> - (strlen(mac_byte) <= 2) &&
> - (strlen(mac_byte) == strspn(mac_byte,
> - ETH_TAP_CMP_MAC_FMT))) {
> - user_mac->addr_bytes[index++] = strtoul(mac_byte, NULL, 16);
> - mac_byte = strtok(NULL, ":");
> - }
> -
> - return index;
> -}
> -
> static int
> set_mac_type(const char *key __rte_unused,
> const char *value,
> @@ -2311,7 +2288,7 @@ set_mac_type(const char *key __rte_unused,
> goto success;
> }
>
> - if (parse_user_mac(user_mac, value) != 6)
> + if (rte_ether_unformat_addr(value, user_mac) < 0)
> goto error;
> success:
> TAP_LOG(DEBUG, "TAP user MAC param (%s)", value);
There might still be case where user_mac == NULL since it comes
from extra_args.
Also, this code has this suspicious code:
if (!strncasecmp(ETH_TAP_MAC_FIXED, value, strlen(ETH_TAP_MAC_FIXED))) {
static int iface_idx;
/* fixed mac = 00:64:74:61:70:<iface_idx> */
memcpy((char *)user_mac->addr_bytes, "\0dtap",
RTE_ETHER_ADDR_LEN);
user_mac->addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
iface_idx++ + '0';
goto success;
}
The OUI for that MAC address is not registered but it might be someday.
Choosing magic constants in IANA assigned space is not best practice.
Unless some vendor wants to spend lots of time registering these.
Better to use locally assigned value. See RFC7042 for more details.