gcc 8.2 reports stringop-truncation when building qemu
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| QEMU |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
QEMU 3.0
block/sheepdog.c: In function 'find_vdi_name':
block/sheepdog.
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_
^~
If this is the intended behavior, please suppress the warning. For example:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_
#pragma GCC diagnostic pop
This also happens on other sources, for example hw/acpi/core.c, so another option is to suppress it globally on CFLAGS (-Wno-stringop-
| description: | updated |
| elmarco (marcandre-lureau) wrote : Re: [Qemu-devel] [PATCH v2 3/3] migration: Replace strncpy() by strpadcpy(pad='\0') | #1 |
| Igor (imammedo) wrote : Re: [Qemu-devel] [PATCH v2 1/3] hw/acpi: Replace strncpy() by strpadcpy(pad='\0') | #2 |
On Tue, 18 Dec 2018 12:03:31 +0100
Philippe Mathieu-Daudé <email address hidden> wrote:
> From: Marc-André Lureau <email address hidden>
>
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC hw/acpi/core.o
> In function 'acpi_table_
> qemu/hw/
> strncpy(
> ^~~~~~~
> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1
>
> The ACPI tables don't require the strings to be NUL-terminated,
> therefore strncpy is the right function to use here.
>
> We could add a #pragma GCC diagnostic ignored "-Wstringop-
> around, disable the warning globally using -Wno-stringop-
> but since QEMU provides the strpadcpy() which does the same purpose,
> simply use it to avoid the annoying warning.
>
> Signed-off-by: Marc-André Lureau <email address hidden>
> Reviewed-by: Eric Blake <email address hidden>
> Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
> [PMD: reword commit subject and description]
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Reviewed-by: Igor Mammedov <email address hidden>
> ---
> hw/acpi/aml-build.c | 6 ++++--
> hw/acpi/core.c | 13 +++++++------
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/hw/acpi/
> index 1e43cd736d.
> --- a/hw/acpi/
> +++ b/hw/acpi/
> @@ -24,6 +24,7 @@
> #include "hw/acpi/
> #include "qemu/bswap.h"
> #include "qemu/bitops.h"
> +#include "qemu/cutils.h"
> #include "sysemu/numa.h"
>
> static GArray *build_
> @@ -1532,13 +1533,14 @@ build_header(
> h->revision = rev;
>
> if (oem_id) {
> - strncpy((char *)h->oem_id, oem_id, sizeof h->oem_id);
> + strpadcpy((char *)h->oem_id, sizeof h->oem_id, oem_id, '\0');
> } else {
> memcpy(h->oem_id, ACPI_BUILD_
> }
>
> if (oem_table_id) {
> - strncpy((char *)h->oem_table_id, oem_table_id, sizeof(
> + strpadcpy((char *)h->oem_table_id, sizeof(
> + oem_table_id, '\0');
> } else {
> memcpy(
> memcpy(
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index aafdc61648.
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -31,6 +31,7 @@
> #include "qapi/qapi-
> #include "qemu/error-
> #include "qemu/option.h"
> +#include "qemu/cutils.h"
>
> struct acpi_table_header {
> uint16_t _length; ...
| mst (mst-0) wrote : Re: [PATCH v2 0/3] Fix strncpy() warnings for GCC8 new -Wstringop-truncation | #3 |
On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote:
> GCC 8 new warning prevents builds to success since quite some time.
> First report on the mailing list is in July 2018:
> https:/
>
> Various intents has been sent to fix this:
> - Incorrectly using g_strlcpy()
> https:/
> https:/
> - Using assert() and strpadcpy()
> https:/
> - Use #pragma GCC diagnostic ignored "-Wstringop-
> https:/
> - adding an inline wrapper with said pragma in there
> https:/
> - -Wno-stringop-
> https:/
>
> This series replace the strncpy() calls by strpadcpy() which seemed
> to me the saniest option.
>
> Regards,
>
> Phil.
Do you happen to know why does it build fine with
Gcc 8.2.1?
Reading the GCC manual it seems that
there is a "nostring" attribute that means
"might not be 0 terminated".
I think we should switch to that which fixes the warning
but also warns if someone tries to misuse these
as C-strings.
Seems to be a better option, does it not?
> Marc-André Lureau (1):
> hw/acpi: Replace strncpy() by strpadcpy(pad='\0')
>
> Philippe Mathieu-Daudé (2):
> block/sheepdog: Replace strncpy() by strpadcpy(pad='\0')
> migration: Replace strncpy() by strpadcpy(pad='\0')
>
> block/sheepdog.c | 6 +++---
> hw/acpi/aml-build.c | 6 ++++--
> hw/acpi/core.c | 13 +++++++------
> migration/
> 4 files changed, 16 insertions(+), 13 deletions(-)
>
> --
> 2.17.2
| Daniel Berrange (berrange) wrote : | #4 |
On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote:
> > GCC 8 new warning prevents builds to success since quite some time.
> > First report on the mailing list is in July 2018:
> > https:/
> >
> > Various intents has been sent to fix this:
> > - Incorrectly using g_strlcpy()
> > https:/
> > https:/
> > - Using assert() and strpadcpy()
> > https:/
> > - Use #pragma GCC diagnostic ignored "-Wstringop-
> > https:/
> > - adding an inline wrapper with said pragma in there
> > https:/
> > - -Wno-stringop-
> > https:/
> >
> > This series replace the strncpy() calls by strpadcpy() which seemed
> > to me the saniest option.
> >
> > Regards,
> >
> > Phil.
>
> Do you happen to know why does it build fine with
> Gcc 8.2.1?
>
> Reading the GCC manual it seems that
> there is a "nostring" attribute that means
typo - its "nonstring"
> "might not be 0 terminated".
> I think we should switch to that which fixes the warning
> but also warns if someone tries to misuse these
> as C-strings.
>
> Seems to be a better option, does it not?
Yes, it does look best as gcc manual explicitly suggests "nonstring"
as the way to stop this strncpy warning.
Regards,
Daniel
--
|: https:/
|: https:/
|: https:/
| mst (mst-0) wrote : | #5 |
On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote:
> > GCC 8 new warning prevents builds to success since quite some time.
> > First report on the mailing list is in July 2018:
> > https:/
> >
> > Various intents has been sent to fix this:
> > - Incorrectly using g_strlcpy()
> > https:/
> > https:/
> > - Using assert() and strpadcpy()
> > https:/
> > - Use #pragma GCC diagnostic ignored "-Wstringop-
> > https:/
> > - adding an inline wrapper with said pragma in there
> > https:/
> > - -Wno-stringop-
> > https:/
> >
> > This series replace the strncpy() calls by strpadcpy() which seemed
> > to me the saniest option.
> >
> > Regards,
> >
> > Phil.
>
> Do you happen to know why does it build fine with
> Gcc 8.2.1?
>
> Reading the GCC manual it seems that
> there is a "nostring" attribute
Sorry that should be "nonstring".
> that means
> "might not be 0 terminated".
> I think we should switch to that which fixes the warning
> but also warns if someone tries to misuse these
> as C-strings.
>
> Seems to be a better option, does it not?
>
Also maybe we can make strpadcpy check for the nonstring
attribute too somehow?
Or did gcc just hardcode the strncpy name?
> > Marc-André Lureau (1):
> > hw/acpi: Replace strncpy() by strpadcpy(pad='\0')
> >
> > Philippe Mathieu-Daudé (2):
> > block/sheepdog: Replace strncpy() by strpadcpy(pad='\0')
> > migration: Replace strncpy() by strpadcpy(pad='\0')
> >
> > block/sheepdog.c | 6 +++---
> > hw/acpi/aml-build.c | 6 ++++--
> > hw/acpi/core.c | 13 +++++++------
> > migration/
> > 4 files changed, 16 insertions(+), 13 deletions(-)
> >
> > --
> > 2.17.2
| mst (mst-0) wrote : | #6 |
On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote:
> On 18/12/18 15:31, Michael S. Tsirkin wrote:
> > Do you happen to know why does it build fine with
> > Gcc 8.2.1?
> >
> > Reading the GCC manual it seems that
> > there is a "nostring" attribute that means
> > "might not be 0 terminated".
> > I think we should switch to that which fixes the warning
> > but also warns if someone tries to misuse these
> > as C-strings.
> >
> > Seems to be a better option, does it not?
> >
> >
>
> Using strpadcpy is clever and self-documenting, though. We have it
> already, so why not use it.
>
> Paolo
The advantage of nonstring is that it will catch attempts to
use these fields with functions that expect a 0 terminated string.
strpadcpy will instead just silence the warning.
--
MST
| mst (mst-0) wrote : | #7 |
On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote:
> On 18/12/18 15:54, Michael S. Tsirkin wrote:
> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote:
> >> On 18/12/18 15:31, Michael S. Tsirkin wrote:
> >>> Do you happen to know why does it build fine with
> >>> Gcc 8.2.1?
> >>>
> >>> Reading the GCC manual it seems that
> >>> there is a "nostring" attribute that means
> >>> "might not be 0 terminated".
> >>> I think we should switch to that which fixes the warning
> >>> but also warns if someone tries to misuse these
> >>> as C-strings.
> >>>
> >>> Seems to be a better option, does it not?
> >>>
> >>>
> >>
> >> Using strpadcpy is clever and self-documenting, though. We have it
> >> already, so why not use it.
> >>
> >> Paolo
> >
> > The advantage of nonstring is that it will catch attempts to
> > use these fields with functions that expect a 0 terminated string.
> >
> > strpadcpy will instead just silence the warning.
>
> Ah, I see. We could also do both, that's a matter of taste.
>
> Paolo
Do you happen to know how to make gcc check the buffer size
for strpadcpy? Is the name strncpy just hard-coded?
--
MST
| mst (mst-0) wrote : | #8 |
On Tue, Dec 18, 2018 at 05:55:27PM +0100, Philippe Mathieu-Daudé wrote:
> On 12/18/18 3:54 PM, Michael S. Tsirkin wrote:
> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote:
> >> On 18/12/18 15:31, Michael S. Tsirkin wrote:
> >>> Do you happen to know why does it build fine with
> >>> Gcc 8.2.1?
> >>>
> >>> Reading the GCC manual it seems that
> >>> there is a "nostring" attribute that means
> >>> "might not be 0 terminated".
> >>> I think we should switch to that which fixes the warning
> >>> but also warns if someone tries to misuse these
> >>> as C-strings.
> >>>
> >>> Seems to be a better option, does it not?
> >>>
> >>>
> >>
> >> Using strpadcpy is clever and self-documenting, though. We have it
> >> already, so why not use it.
> >>
> >> Paolo
> >
> > The advantage of nonstring is that it will catch attempts to
> > use these fields with functions that expect a 0 terminated string.
> >
> > strpadcpy will instead just silence the warning.
>
> migration/
> attribute 'nonstring' [-Werror=
> s->size = strlen((char *)s->runstate) + 1;
> ^~~~~~~
>
> GCC won... It is true this strlen() is buggy, indeed s->runstate might
> be not NUL-terminated.
Ooh nice. I smell some CVE fixes coming from this effort.
--
MST
| mst (mst-0) wrote : | #9 |
On Tue, Dec 18, 2018 at 06:12:05PM +0100, Paolo Bonzini wrote:
> On 18/12/18 17:55, Philippe Mathieu-Daudé wrote:
> >> strpadcpy will instead just silence the warning.
> > migration/
> > attribute 'nonstring' [-Werror=
> > s->size = strlen((char *)s->runstate) + 1;
> > ^~~~~~~
> >
> > GCC won... It is true this strlen() is buggy, indeed s->runstate might
> > be not NUL-terminated.
>
> No, runstate is declared as an array of 100 bytes, which are more than
> enough. It's ugly code but not buggy.
>
> Paolo
Yes ... but it is loaded using
and parsed using qapi_enum_parse which does not get
the buffer length.
So unless we are lucky there's a buffer overrun
on a remote/file input here.
Seems buggy to me - what am I missing?
--
MST
| Daniel Berrange (berrange) wrote : | #10 |
On Tue, Dec 18, 2018 at 12:03:34PM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote:
> > On 18/12/18 15:54, Michael S. Tsirkin wrote:
> > > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote:
> > >> On 18/12/18 15:31, Michael S. Tsirkin wrote:
> > >>> Do you happen to know why does it build fine with
> > >>> Gcc 8.2.1?
> > >>>
> > >>> Reading the GCC manual it seems that
> > >>> there is a "nostring" attribute that means
> > >>> "might not be 0 terminated".
> > >>> I think we should switch to that which fixes the warning
> > >>> but also warns if someone tries to misuse these
> > >>> as C-strings.
> > >>>
> > >>> Seems to be a better option, does it not?
> > >>>
> > >>>
> > >>
> > >> Using strpadcpy is clever and self-documenting, though. We have it
> > >> already, so why not use it.
> > >>
> > >> Paolo
> > >
> > > The advantage of nonstring is that it will catch attempts to
> > > use these fields with functions that expect a 0 terminated string.
> > >
> > > strpadcpy will instead just silence the warning.
> >
> > Ah, I see. We could also do both, that's a matter of taste.
> >
> > Paolo
>
> Do you happen to know how to make gcc check the buffer size
> for strpadcpy? Is the name strncpy just hard-coded?
GCC provides strncpy as a builtin function and its warning only
checks its builtin.
Regards,
Daniel
--
|: https:/
|: https:/
|: https:/
| Eric Blake (eblake) wrote : Re: [PATCH v3 1/5] qemu/compiler: Define QEMU_NONSTRING | #11 |
On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote:
> GCC 8 introduced the -Wstringop-
> the strncat and strncpy functions (closely related to -Wstringop-
> which detect buffer overflow by string-modifying functions declared in
> <string.h>).
This paragraph talks about a new warning checker, but makes no mention
of an attribute.
>
> Add the QEMU_NONSTRING macro which checks if the compiler supports this
> attribute.
Thus, "this attribute" has no antecedent; did you forget to add a
sentence to the previous paragraph, or maybe put the mention of adding
QEMU_NONSTRING after...
>
>>From the GCC manual [*]:
>
> The nonstring variable attribute specifies that an object or member
> declaration with type array of char, signed char, or unsigned char,
> or pointer to such a type is intended to store character arrays that
> do not necessarily contain a terminating NUL. This is useful in detecting
> uses of such arrays or pointers with functions that expect NUL-terminated
> strings, and to avoid warnings when such an array or pointer is used as
> an argument to a bounded string manipulation function such as strncpy.
...the explanation of how the attribute was added in tandem with the new
warning checker for silencing specific instances of the warning?
>
> [*] https:/
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> include/
> 1 file changed, 15 insertions(+)
>
Reviewed-by: Eric Blake <email address hidden>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
| Eric Blake (eblake) wrote : Re: [PATCH v3 2/5] block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays | #12 |
On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC block/sheepdog.o
> qemu/block/
> qemu/block/
> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1
>
> As described previous to the strncpy() calls, the use of strncpy() is
> correct here:
>
> /* 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_
>
> Use the QEMU_NONSTRING attribute, since this array is intended to store
> character arrays that do not necessarily contain a terminating NUL.
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> block/sheepdog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Eric Blake <email address hidden>
>
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 0125df9d49.
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -1224,7 +1224,7 @@ static int find_vdi_
> SheepdogVdiReq hdr;
> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
> unsigned int wlen, rlen = 0;
> - char buf[SD_MAX_VDI_LEN + SD_MAX_
> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_
>
> fd = connect_to_sdog(s, errp);
> if (fd < 0) {
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
| Eric Blake (eblake) wrote : Re: [PATCH v3 4/5] migration: Use QEMU_NONSTRING for non NUL-terminated arrays | #13 |
On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> strncpy((char *)global_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: migration/
>
> Use the QEMU_NONSTRING attribute, since this array is intended to store
> character arrays that do not necessarily contain a terminating NUL.
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> migration/
> 1 file changed, 1 insertion(+), 1 deletion(-)
Should this be squashed with 5/5?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
| Eric Blake (eblake) wrote : Re: [PATCH v3 5/5] migration: Use strnlen() for fixed-size string | #14 |
On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote:
> GCC 8 introduced the -Wstringop-
> by string-modifying functions declared in <string.h>, such strncpy(),
> used in global_
>
> Since the global_
> terminating NUL character, We had to use the QEMU_NONSTRING attribute.
s/We/we/
>
> The GCC manual says about the nonstring attribute:
>
> However, when the array is declared with the attribute the call to
> strlen is diagnosed because when the array doesn’t contain a
> NUL-terminated string the call is undefined. [...]
> In addition, calling strnlen and strndup with such arrays is safe
> provided a suitable bound is specified, and not diagnosed.
>
> GCC indeed found an incorrect use of strlen(), because this array
> is loaded by VMSTATE_
> using qapi_enum_parse which does not get the buffer length.
>
> Use strnlen() which returns sizeof(s->runstate) if the array is not
> NUL-terminated.
>
> This fixes:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> s->size = strlen((char *)s->runstate) + 1;
> ^~~~~~~
> qemu/migration/
> uint8_t runstate[100] QEMU_NONSTRING;
> ^~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [qemu/rules.mak:69: migration/
>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> migration/
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/
> index 6e19333422.
> --- a/migration/
> +++ b/migration/
> @@ -106,7 +106,7 @@ static int global_
> GlobalState *s = opaque;
>
> trace_migrate_
> - s->size = strlen((char *)s->runstate) + 1;
The old code sets s->size to the string length + space for the NUL byte
(by assuming that a NUL byte was present), and accidentally sets it
beyond the s->runstate array if there was no NUL byte (our existing
runstate names are shorter than 100 bytes, so this could only happen on
a malicious stream).
> + s->size = strnlen((char *)s->runstate, sizeof(
The new code can still end up setting s->size beyond the array. Is that
intended, or would it be better to use strnlen(
sizeof(s->runstate) - 1) + 1?
Also, as I argued on 4/5, why isn't this squashed in with the patch that
marks the field NONSTRING?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
| Eric Blake (eblake) wrote : Re: [PATCH v3 4/5] migration: Use QEMU_NONSTRING for non NUL-terminated arrays | #15 |
On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> strncpy((char *)global_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: migration/
>
> Use the QEMU_NONSTRING attribute, since this array is intended to store
> character arrays that do not necessarily contain a terminating NUL.
> typedef struct {
> uint32_t size;
> - uint8_t runstate[100];
> + uint8_t runstate[100] QEMU_NONSTRING;
Since 100 bytes for runstate[] is larger than any string possible in our
current enum string values, could we instead add an assert that
strlen(state) < sizeof(
to make our intent obvious while still shutting up the compiler warning,
but without having to deal with the fallout of marking runstate as a
non-string?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
| mst (mst-0) wrote : Re: [PATCH v3 0/5] Fix strncpy() warnings for GCC8 new -Wstringop-truncation | #16 |
On Tue, Dec 18, 2018 at 06:51:17PM +0100, Philippe Mathieu-Daudé wrote:
> GCC 8 new warning prevents builds to success since quite some time.
> First report on the mailing list is in July 2018:
> https:/
>
> Various intents has been sent to fix this:
> - Incorrectly using g_strlcpy()
> https:/
> https:/
> - Using assert() and strpadcpy()
> https:/
> - Use #pragma GCC diagnostic ignored "-Wstringop-
> https:/
> - adding an inline wrapper with said pragma in there
> https:/
> - -Wno-stringop-
> https:/
> - Use the 'nonstring' attribute
> https:/
>
> This series add the QEMU_NONSTRING definition and use it.
>
> Regards,
>
> Phil.
Reviewed-by: Michael S. Tsirkin <email address hidden>
> Philippe Mathieu-Daudé (5):
> qemu/compiler: Define QEMU_NONSTRING
> block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays
> hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays
> migration: Use QEMU_NONSTRING for non NUL-terminated arrays
> migration: Use strnlen() for fixed-size string
>
> block/sheepdog.c | 2 +-
> hw/acpi/core.c | 8 ++++----
> include/
> include/
> migration/
> 5 files changed, 26 insertions(+), 11 deletions(-)
>
> --
> 2.17.2
| mst (mst-0) wrote : Re: [PATCH v3 2/5] block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays | #17 |
On Tue, Dec 18, 2018 at 06:51:19PM +0100, Philippe Mathieu-Daudé wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC block/sheepdog.o
> qemu/block/
> qemu/block/
> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1
>
> As described previous to the strncpy() calls, the use of strncpy() is
> correct here:
>
> /* 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_
>
> Use the QEMU_NONSTRING attribute, since this array is intended to store
> character arrays that do not necessarily contain a terminating NUL.
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> block/sheepdog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 0125df9d49.
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -1224,7 +1224,7 @@ static int find_vdi_
> SheepdogVdiReq hdr;
> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
> unsigned int wlen, rlen = 0;
> - char buf[SD_MAX_VDI_LEN + SD_MAX_
> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_
In case you decide to respin anyway - this would be
a bit nicer as:
char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN] QEMU_NONSTRING
> fd = connect_to_sdog(s, errp);
> if (fd < 0) {
> --
> 2.17.2
| mst (mst-0) wrote : Re: [PATCH v3 5/5] migration: Use strnlen() for fixed-size string | #18 |
On Tue, Dec 18, 2018 at 06:51:22PM +0100, Philippe Mathieu-Daudé wrote:
> GCC 8 introduced the -Wstringop-
> by string-modifying functions declared in <string.h>, such strncpy(),
> used in global_
>
> Since the global_
> terminating NUL character, We had to use the QEMU_NONSTRING attribute.
>
> The GCC manual says about the nonstring attribute:
>
> However, when the array is declared with the attribute the call to
> strlen is diagnosed because when the array doesn’t contain a
> NUL-terminated string the call is undefined. [...]
> In addition, calling strnlen and strndup with such arrays is safe
> provided a suitable bound is specified, and not diagnosed.
>
> GCC indeed found an incorrect use of strlen(), because this array
> is loaded by VMSTATE_
> using qapi_enum_parse which does not get the buffer length.
>
> Use strnlen() which returns sizeof(s->runstate) if the array is not
> NUL-terminated.
>
> This fixes:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> s->size = strlen((char *)s->runstate) + 1;
> ^~~~~~~
> qemu/migration/
> uint8_t runstate[100] QEMU_NONSTRING;
> ^~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [qemu/rules.mak:69: migration/
>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> migration/
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/
> index 6e19333422.
> --- a/migration/
> +++ b/migration/
> @@ -106,7 +106,7 @@ static int global_
> GlobalState *s = opaque;
>
> trace_migrate_
> - s->size = strlen((char *)s->runstate) + 1;
> + s->size = strnlen((char *)s->runstate, sizeof(
>
> return 0;
I don't think this works correctly if strnlen returns
sizeof(
jus add
assert(e->size is <= sizeof(
But also I think this is not enough, there's a problem in post-load
in the call to qapi_enum_parse. You probably want to force
the last character to 0 there.
> }
> --
> 2.17.2
| Igor (imammedo) wrote : Re: [Qemu-devel] [PATCH v3 3/5] hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays | #19 |
On Tue, 18 Dec 2018 18:51:20 +0100
Philippe Mathieu-Daudé <email address hidden> wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC hw/acpi/core.o
> In function 'acpi_table_
> qemu/hw/
> strncpy(
> ^~~~~~~
> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1
>
> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the
> strings to be NUL-terminated.
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> hw/acpi/core.c | 8 ++++----
> include/
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index aafdc61648.
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -35,14 +35,14 @@
> struct acpi_table_header {
> uint16_t _length; /* our length, not actual part of the hdr */
> /* allows easier parsing for fw_cfg clients */
> - char sig[4]; /* ACPI signature (4 ASCII characters) */
> + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters) */
> uint32_t length; /* Length of table, in bytes, including header */
> uint8_t revision; /* ACPI Specification minor version # */
> uint8_t checksum; /* To make sum of entire table == 0 */
> - char oem_id[6]; /* OEM identification */
> - char oem_table_id[8]; /* OEM table identification */
> + char oem_id[6] QEMU_NONSTRING; /* OEM identification */
> + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */
> uint32_t oem_revision; /* OEM revision number */
> - char asl_compiler_id[4]; /* ASL compiler vendor ID */
> + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */
> uint32_t asl_compiler_
> } QEMU_PACKED;
>
> diff --git a/include/
> index af8e023968.
> --- a/include/
> +++ b/include/
> @@ -43,7 +43,7 @@ enum {
> struct AcpiRsdpDescriptor { /* Root System Descriptor Pointer */
> uint64_t signature; /* ACPI signature, contains "RSD PTR " */
> uint8_t checksum; /* To make sum of struct == 0 */
> - uint8_t oem_id [6]; /* OEM identification */
> + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */
> uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */
> uint32_t rsdt_physica...
| Igor (imammedo) wrote : | #20 |
On Wed, 19 Dec 2018 10:20:36 +0100
Philippe Mathieu-Daudé <email address hidden> wrote:
> Le mer. 19 déc. 2018 10:16, Igor Mammedov <email address hidden> a écrit :
>
> > On Tue, 18 Dec 2018 18:51:20 +0100
> > Philippe Mathieu-Daudé <email address hidden> wrote:
> >
> > > GCC 8 added a -Wstringop-
> > >
> > > The -Wstringop-
> > > bug 81117 is specifically intended to highlight likely unintended
> > > uses of the strncpy function that truncate the terminating NUL
> > > character from the source string.
> > >
> > > This new warning leads to compilation failures:
> > >
> > > CC hw/acpi/core.o
> > > In function 'acpi_table_
> > qemu/hw/
> > > qemu/hw/
> > destination size [-Werror=
> > > strncpy(
> > > ^~~~~~~
> > > make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1
> > >
> > > Use the QEMU_NONSTRING attribute, since ACPI tables don't require the
> > > strings to be NUL-terminated.
> > >
> > > Suggested-by: Michael S. Tsirkin <email address hidden>
> > > Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> > > ---
> > > hw/acpi/core.c | 8 ++++----
> > > include/
> > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> > > index aafdc61648.
> > > --- a/hw/acpi/core.c
> > > +++ b/hw/acpi/core.c
> > > @@ -35,14 +35,14 @@
> > > struct acpi_table_header {
> > > uint16_t _length; /* our length, not actual part of the hdr
> > */
> > > /* allows easier parsing for fw_cfg
> > clients */
> > > - char sig[4]; /* ACPI signature (4 ASCII characters) */
> > > + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters)
> > */
> > > uint32_t length; /* Length of table, in bytes, including
> > header */
> > > uint8_t revision; /* ACPI Specification minor version # */
> > > uint8_t checksum; /* To make sum of entire table == 0 */
> > > - char oem_id[6]; /* OEM identification */
> > > - char oem_table_id[8]; /* OEM table identification */
> > > + char oem_id[6] QEMU_NONSTRING; /* OEM identification */
> > > + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */
> > > uint32_t oem_revision; /* OEM revision number */
> > > - char asl_compiler_id[4]; /* ASL compiler vendor ID */
> > > + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */
> > > uint32_t asl_compiler_
> > > } QEMU_PACKED;
> > >
> > > diff --git a/include/
> > > index af8e023968.
> > > --- a/include/
> > > +++ b/include/
> > > @@ -43,7 +43,7 @@ enum {
> > > struct AcpiRsdpDescrip
| Igor (imammedo) wrote : | #21 |
On Wed, 19 Dec 2018 14:00:37 +0100
Andrew Jones <email address hidden> wrote:
> On Wed, Dec 19, 2018 at 01:43:40PM +0100, Philippe Mathieu-Daudé wrote:
> > Hi Drew,
> >
> > On 12/19/18 11:10 AM, Andrew Jones wrote:
> > > On Tue, Dec 18, 2018 at 06:51:20PM +0100, Philippe Mathieu-Daudé wrote:
> > >> GCC 8 added a -Wstringop-
> > >>
> > >> The -Wstringop-
> > >> bug 81117 is specifically intended to highlight likely unintended
> > >> uses of the strncpy function that truncate the terminating NUL
> > >> character from the source string.
> > >>
> > >> This new warning leads to compilation failures:
> > >>
> > >> CC hw/acpi/core.o
> > >> In function 'acpi_table_
> > >> qemu/hw/
> > >> strncpy(
> > >> ^~~~~~~
> > >> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1
> > >>
> > >> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the
> > >> strings to be NUL-terminated.
> > >
> > > Aren't we always starting with zero-initialized structures in ACPI code?
> > > If so, then we should be able to change the strncpy's to memcpy's.
> >
> > The first call zero-initializes, but then we call realloc():
> >
> > /* We won't fail from here on. Initialize / extend the globals. */
> > if (acpi_tables == NULL) {
> > acpi_tables_len = sizeof(uint16_t);
> > acpi_tables = g_malloc0(
> > }
> >
> > acpi_tables = g_realloc(
> > ACPI_TABLE_PFX_SIZE +
> > sizeof dfl_hdr + body_size);
> >
> > ext_hdr = (struct acpi_table_header *)(acpi_tables +
> > acpi_tables_len);
> >
> > So memcpy() isn't enough.
>
> Ah, thanks.
>
> >
> > I can resend the previous patch which uses strpadcpy() if you prefer,
> > Igor already reviewed it:
> >
> > https:/
> >
>
> I do like strpadcpy() better, but I'm not going to lose sleep about
> this either way it goes.
I'm ok with both ways, but v2 consensus was to use QEMU_NONSTRING if I got it right
>
> Thanks,
> drew
| Dr. David Alan Gilbert (dgilbert-h) wrote : Re: [PATCH v3 4/5] migration: Use QEMU_NONSTRING for non NUL-terminated arrays | #22 |
* Philippe Mathieu-Daudé (<email address hidden>) wrote:
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> strncpy((char *)global_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: migration/
>
> Use the QEMU_NONSTRING attribute, since this array is intended to store
> character arrays that do not necessarily contain a terminating NUL.
>
> Suggested-by: Michael S. Tsirkin <email address hidden>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
> ---
> migration/
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/
> index 8e8ab5c51e.
> --- a/migration/
> +++ b/migration/
> @@ -21,7 +21,7 @@
>
> typedef struct {
> uint32_t size;
> - uint8_t runstate[100];
> + uint8_t runstate[100] QEMU_NONSTRING;
Hmm; global_
uses s->runsate and ends up passing it to both a trace
and a qapi_enum_parse - so it's really treating it as a string.
That code is unsafe anyway since it's assuming the received
runstate would be terminated.
Dave
> RunState state;
> bool received;
> } GlobalState;
> --
> 2.17.2
>
--
Dr. David Alan Gilbert / <email address hidden> / Manchester, UK
| Peter Maydell (pmaydell) wrote : | #23 |
We think we've fixed all the GCC 8.2 stringop-truncation warnings now, so current QEMU git master and the 4.0 rc1 we've just tagged should both build cleanly. Please reopen the bug if we missed one somehow.
| Changed in qemu: | |
| status: | New → Fix Committed |
| Changed in qemu: | |
| status: | Fix Committed → Fix Released |

On Tue, Dec 18, 2018 at 3:09 PM Philippe Mathieu-Daudé truncation warning: truncation warning added in GCC 8.0 via r254630 for global_ state.o global_ state.c: In function 'global_ state_store_ running' : global_ state.c: 45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror= stringop- truncation] state.runstate, state, sizeof( global_ state.runstate) ); ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~ global_ state.o] Error 1 truncation" truncation,
<email address hidden> wrote:
>
> GCC 8 added a -Wstringop-
>
> The -Wstringop-
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC migration/
> qemu/migration/
> qemu/migration/
> strncpy((char *)global_
> ^~~~~~~
> make: *** [qemu/rules.mak:69: migration/
>
> The runstate name doesn't require the strings to be NUL-terminated,
> therefore strncpy is the right function to use here.
>
> We could add a #pragma GCC diagnostic ignored "-Wstringop-
> around, disable the warning globally using -Wno-stringop-
> but since QEMU provides the strpadcpy() which does the same purpose,
> simply use it to avoid the annoying warning.
>
> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Reviewed-by: Marc-André Lureau <email address hidden>
> --- global_ state.c | 4 ++-- global_ state.c b/migration/ global_ state.c .c7e7618118 100644 global_ state.c global_ state.c state_store( void) state_store_ running( void) str(RUN_ STATE_RUNNING) ; state.runstate, global_ state.runstate) ); state.runstate, global_ state.runstate) , state, '\0'); state_received( void)
> migration/
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/migration/
> index 8e8ab5c51e.
> --- a/migration/
> +++ b/migration/
> @@ -42,8 +42,8 @@ int global_
> void global_
> {
> const char *state = RunState_
> - strncpy((char *)global_
> - state, sizeof(
> + strpadcpy((char *)global_
> + sizeof(
> }
>
> bool global_
> --
> 2.17.2
>
>
--
Marc-André Lureau