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