All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Fan Zhang <roy.fan.zhang@intel.com>,
	 Maxime Coquelin <maxime.coquelin@redhat.com>,
	Chenbo Xia <chenbo.xia@intel.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	 Ferruh Yigit <ferruh.yigit@xilinx.com>,
	dpdk stable <stable@dpdk.org>
Subject: Re: [PATCH 10/12] vhost/crypto: fix build with GCC 12
Date: Tue, 14 Jun 2022 11:22:24 +0200	[thread overview]
Message-ID: <CAJFAV8wi6JucKwzxsCQWQ2bQ0_V5+JRY7BW2fsvbQGGAW=8nmw@mail.gmail.com> (raw)
In-Reply-To: <YpiMLYFry0vzlEtq@bricha3-MOBL.ger.corp.intel.com>

On Thu, Jun 2, 2022 at 12:09 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Wed, May 18, 2022 at 12:16:55PM +0200, David Marchand wrote:
> > GCC 12 raises the following warning:
> >
> > In file included from ../lib/mempool/rte_mempool.h:46,
> >                  from ../lib/mbuf/rte_mbuf.h:38,
> >                  from ../lib/vhost/vhost_crypto.c:7:
> > ../lib/vhost/vhost_crypto.c: In function ‘rte_vhost_crypto_fetch_requests’:
> > ../lib/eal/x86/include/rte_memcpy.h:371:9: warning: array subscript 1 is
> >      outside array bounds of ‘struct virtio_crypto_op_data_req[1]’
> >      [-Warray-bounds]
> >   371 | rte_mov32((uint8_t *)dst + 3 * 32, (const uint8_t *)src + 3 * 32);
> >       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../lib/vhost/vhost_crypto.c:1178:42: note: while referencing ‘req’
> >  1178 |         struct virtio_crypto_op_data_req req;
> >       |                                          ^~~
> >
> > Check that copied length is within req boundaries.
> >
> > Fixes: 3c79609fda7c ("vhost/crypto: handle virtually non-contiguous buffers")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> >  lib/vhost/vhost_crypto.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
> > index b1c0eb6a0f..83325b7042 100644
> > --- a/lib/vhost/vhost_crypto.c
> > +++ b/lib/vhost/vhost_crypto.c
> > @@ -576,16 +576,16 @@ copy_data(void *dst_data, struct vhost_crypto_data_req *vc_req,
> >       uint32_t to_copy;
> >       uint8_t *data = dst_data;
> >       uint8_t *src;
> > -     int left = size;
> > +     uint32_t left = size;
> >
> > -     to_copy = RTE_MIN(desc->len, (uint32_t)left);
> > +     to_copy = RTE_MIN(desc->len, left);
> >       dlen = to_copy;
> >       src = IOVA_TO_VVA(uint8_t *, vc_req, desc->addr, &dlen,
> >                       VHOST_ACCESS_RO);
>
> Tracking the functions which end up being called by this macro, the dlen
> parameter ends up being of type "uint64_t *", passing a value of int * or
> uint32_t * seems wrong to me. If we are changing the type from int to
> uint32_t, I think it should be promoted all the way to uint64_t.

Indeed.
I'll update in v2.

We already had some CVE on this part of the code, a careful review is needed.


>
> > -     if (unlikely(!src || !dlen))
> > +     if (unlikely(!src || !dlen || dlen > left))
> >               return -1;
> >
>
> If this change is omitted, does the compiler still give warnings. Looking
> through the called code, the dlen parameter can only ever be reduced, not
> incremented (function rte_vhost_va_from_guest_pa() in rte_vhost.h).

If I promote to_copy and left variables as uint64_t, gcc is still
unhappy, for the same reason.
The check on dlen > left seems necessary.


>
> > -     rte_memcpy((uint8_t *)data, src, dlen);
> > +     rte_memcpy(data, src, dlen);
> >       data += dlen;
> >
> >       if (unlikely(dlen < to_copy)) {
> > --
> > 2.36.1
> >
>

-- 
David Marchand


  reply	other threads:[~2022-06-14  9:22 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 10:16 [PATCH 00/12] Fix compilation with gcc 12 David Marchand
2022-05-18 10:16 ` [PATCH 01/12] common/cpt: fix build with GCC 12 David Marchand
2022-05-20 20:23   ` Stephen Hemminger
2022-06-10 13:11   ` David Marchand
2022-06-13 11:40     ` [EXT] " Ankur Dwivedi
2022-06-16  9:30       ` David Marchand
2022-06-16 11:59         ` Ankur Dwivedi
2022-05-18 10:16 ` [PATCH 02/12] crypto/cnxk: " David Marchand
2022-05-20 20:24   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 03/12] crypto/ipsec_mb: " David Marchand
2022-06-02  9:50   ` Bruce Richardson
2022-06-10 13:07     ` David Marchand
2022-06-11 15:34   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 04/12] net/ena: " David Marchand
2022-05-20 20:28   ` Stephen Hemminger
2022-05-21  9:49     ` Morten Brørup
2022-05-21 16:23       ` Stephen Hemminger
2022-05-22 20:30         ` Morten Brørup
2022-06-11 15:34   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 05/12] net/enetfec: " David Marchand
2022-06-10 13:08   ` David Marchand
2022-06-13  5:22     ` Sachin Saxena (OSS)
2022-06-14  8:16     ` Sachin Saxena (OSS)
2022-06-11 15:35   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 06/12] net/ice: " David Marchand
2022-06-11 15:36   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 07/12] net/ice/base: " David Marchand
2022-05-18 10:16 ` [PATCH 08/12] net/qede/base: " David Marchand
2022-05-20 20:29   ` Stephen Hemminger
2022-06-21 23:17   ` Stephen Hemminger
2022-06-22 15:42     ` David Marchand
2022-05-18 10:16 ` [PATCH 09/12] vdpa/ifc: " David Marchand
2022-05-18 11:48   ` Wang, Xiao W
2022-06-11 15:36   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 10/12] vhost/crypto: " David Marchand
2022-06-02 10:08   ` Bruce Richardson
2022-06-14  9:22     ` David Marchand [this message]
2022-06-14  9:25       ` Bruce Richardson
2022-06-16  9:27         ` David Marchand
2022-06-11 15:36   ` Stephen Hemminger
2022-06-16  9:32   ` [PATCH v2] " David Marchand
2022-06-16 14:53     ` David Marchand
2022-05-18 10:16 ` [PATCH 11/12] app/flow-perf: " David Marchand
2022-06-02 10:21   ` Bruce Richardson
2022-06-08  9:03   ` Wisam Monther
2022-06-08 12:20     ` David Marchand
2022-06-13  7:49       ` Wisam Monther
2022-06-11 15:37   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 12/12] test/ipsec: " David Marchand
2022-06-02 18:41   ` Medvedkin, Vladimir
2022-06-03  7:45     ` David Marchand
2022-06-03  7:56       ` Bruce Richardson
2022-06-03  9:41         ` David Marchand
2022-06-03 15:57           ` Medvedkin, Vladimir
2022-06-11 15:38   ` Stephen Hemminger
2022-06-16  9:33   ` [PATCH v2] " David Marchand
2022-06-17 12:06     ` David Marchand
2022-06-20  9:07       ` [EXT] " Akhil Goyal
2022-06-20 15:06       ` Medvedkin, Vladimir
2022-06-16 14:46   ` [PATCH v3] vhost/crypto: " David Marchand
2022-06-17 13:59     ` Maxime Coquelin
2022-06-21  9:31     ` Maxime Coquelin
2022-06-22  9:01       ` Poczatek, Jakub
2022-06-22  9:26         ` Zhang, Roy Fan
2022-06-22 14:07         ` David Marchand
2022-06-22 15:21           ` Poczatek, Jakub
2022-06-22 15:31             ` David Marchand
2022-05-20 20:13 ` [PATCH 00/12] Fix compilation with gcc 12 Stephen Hemminger
2022-05-21  9:39   ` Morten Brørup
2022-06-15  8:49 ` David Marchand
2022-06-15 14:45   ` Stephen Hemminger
2022-06-15 14:59     ` Thomas Monjalon
2022-06-15 15:15       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJFAV8wi6JucKwzxsCQWQ2bQ0_V5+JRY7BW2fsvbQGGAW=8nmw@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@xilinx.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.