All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"David Hildenbrand" <david@redhat.com>,
	"Howard Spoelstra" <hsp.cat7@gmail.com>,
	"Hitoshi Mitake" <mitake.hitoshi@lab.ntt.co.jp>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"open list:Sheepdog" <sheepdog@lists.wpkg.org>,
	"open list:Sheepdog" <qemu-block@nongnu.org>,
	qemu-trivial@nongnu.org, Jeff Cody <jcody@redhat.com>,
	qemu-devel@nongnu.org, Liu Yuan <namei.unix@gmail.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] sheepdog: Replace strncpy() by g_strlcpy()
Date: Mon, 20 Aug 2018 15:28:51 +0200	[thread overview]
Message-ID: <5123af35-773e-cf2a-2e41-2198e0af7c61@redhat.com> (raw)
In-Reply-To: <20180818025600.21132-1-f4bug@amsat.org>

On 18/08/2018 04:56, Philippe Mathieu-Daudé wrote:
> Fedora 29 comes with GCC 8.1 which added the 'stringop-truncation' checks.
> 
> Replace the strncpy() calls by g_strlcpy() to avoid the following warning:
> 
>   block/sheepdog.c: In function 'find_vdi_name':
>   block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals
>   destination size [-Werror=stringop-truncation]
>        strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Reported-by: Howard Spoelstra <hsp.cat7@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> See http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg03723.html
> 
>  block/sheepdog.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index b229a664d9..5dc3d0c39e 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -1224,19 +1224,19 @@ static int find_vdi_name(BDRVSheepdogState *s, const char *filename,
>      SheepdogVdiReq hdr;
>      SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
>      unsigned int wlen, rlen = 0;
> -    char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN];
> +    /* Ensures that the buffer is zero-filled,
> +     * which is desirable since we'll soon be sending those bytes, and
> +     * don't want the send_req to read uninitialized data.
> +     */
> +    char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN] = { };
>  
>      fd = connect_to_sdog(s, errp);
>      if (fd < 0) {
>          return fd;
>      }
>  
> -    /* This pair of strncpy calls ensures that the buffer is zero-filled,
> -     * which is desirable since we'll soon be sending those bytes, and
> -     * don't want the send_req to read uninitialized data.
> -     */
> -    strncpy(buf, filename, SD_MAX_VDI_LEN);
> -    strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
> +    g_strlcpy(buf, filename, SD_MAX_VDI_LEN);
> +    g_strlcpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
>  
>      memset(&hdr, 0, sizeof(hdr));
>      if (lock) {
> 

The protocol doesn't require (as far as I can see) the strings to be
NULL-terminated, therefore strncpy is the right function to use here.

However, we should have a check on the length of filename and tag, so
that no truncation is done.  This applies to both strncpy and g_strlcpy.

Indeed I find g_strlcpy to be harmful because it encourages a style
where truncations happen silently.  There are very few cases where
silent truncation is the right thing to do, and in several cases where
you _have to have_ fixed-size buffers, those buffers are sent on the
wire---and then g_strlcpy is wrong, while strncpy is just as good as
memset+strlen+memcpy (and shorter).

Paolo

  parent reply	other threads:[~2018-08-20 13:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-18  2:56 [Qemu-devel] [PATCH] sheepdog: Replace strncpy() by g_strlcpy() Philippe Mathieu-Daudé
2018-08-20  9:59 ` David Hildenbrand
2018-08-20 13:28 ` Paolo Bonzini [this message]
2018-08-20 13:33   ` David Hildenbrand

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=5123af35-773e-cf2a-2e41-2198e0af7c61@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=david@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=hsp.cat7@gmail.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mitake.hitoshi@lab.ntt.co.jp \
    --cc=mreitz@redhat.com \
    --cc=namei.unix@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=sheepdog@lists.wpkg.org \
    /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.