From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Ben Gainey <ben.gainey@arm.com>,
Stephane Eranian <eranian@google.com>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] perf jvmti: Fix gcc string overflow warning
Date: Fri, 31 May 2019 09:05:30 -0300 [thread overview]
Message-ID: <20190531120530.GB17152@kernel.org> (raw)
In-Reply-To: <20190531080307.22628-1-jolsa@kernel.org>
Em Fri, May 31, 2019 at 10:03:07AM +0200, Jiri Olsa escreveu:
> We are getting fake gcc warning when we compile with gcc9 (9.1.1):
>
> CC jvmti/libjvmti.o
> In file included from /usr/include/string.h:494,
> from jvmti/libjvmti.c:5:
> In function ‘strncpy’,
> inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
> /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
> jvmti/libjvmti.c:165:26: note: length computed here
> 165 | size_t file_name_len = strlen(file_name);
> | ^~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> First I wanted to disable the check, but now I think the code
> could be more straight forward. There's no need to check the
> source size, strncpy will do that. We just need to make sure
> the string is correctly terminated.
>
> Cc: Ben Gainey <ben.gainey@arm.com>
> Cc: Stephane Eranian <eranian@google.com>
> Link: http://lkml.kernel.org/n/tip-sve3b63c550wr907e6ui6gx5@git.kernel.org
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> tools/perf/jvmti/libjvmti.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
> index aea7b1fe85aa..00fa0b7f1ad9 100644
> --- a/tools/perf/jvmti/libjvmti.c
> +++ b/tools/perf/jvmti/libjvmti.c
> @@ -162,8 +162,8 @@ copy_class_filename(const char * class_sign, const char * file_name, char * resu
> result[i] = '\0';
> } else {
> /* fallback case */
> - size_t file_name_len = strlen(file_name);
> - strncpy(result, file_name, file_name_len < max_length ? file_name_len : max_length);
> + strncpy(result, file_name, max_length - 1);
> + result[max_length - 1] = 0;
The usual idiom here, if we stay with strncpy is:
strncpy(result, file_name, max_length - 1)[max_length - 1] = 0;
one line instead of two, but there are other possibilities, what I've
done int these cases in tools/perf/ is to switch to strlcpy, so just
flip that 'n' to a 'l' and it should be enough.
For that we just have a copy of the kernel's strlcpy() implementation in
lib/string.c, and it has this doc:
/**
* strlcpy - Copy a C-string into a sized buffer
* @dest: Where to copy the string to
* @src: Where to copy the string from
* @size: size of destination buffer
*
* Compatible with ``*BSD``: the result is always a valid
* NUL-terminated string that fits in the buffer (unless,
* of course, the buffer size is zero). It does not pad
* out the result like strncpy() does.
*/
The kernel folks moved beyond that and in lib/string.c we have:
/**
* strscpy - Copy a C-string into a sized buffer
* @dest: Where to copy the string to
* @src: Where to copy the string from
* @count: Size of destination buffer
*
* Copy the string, or as much of it as fits, into the dest buffer. The
* behavior is undefined if the string buffers overlap. The destination
* buffer is always NUL terminated, unless it's zero-sized.
*
* Preferred to strlcpy() since the API doesn't require reading memory
* from the src string beyond the specified "count" bytes, and since
* the return value is easier to error-check than strlcpy()'s.
* In addition, the implementation is robust to the string changing out
* from underneath it, unlike the current strlcpy() implementation.
*
* Preferred to strncpy() since it always returns a valid string, and
* doesn't unnecessarily force the tail of the destination buffer to be
* zeroed. If zeroing is desired please use strscpy_pad().
*
* Return: The number of characters copied (not including the trailing
* %NUL) or -E2BIG if the destination buffer wasn't big enough.
*/
ssize_t strscpy(char *dest, const char *src, size_t count)
I think for these needs flipping that 'n' into a 'l' is good enough.
- Arnaldo
> }
> }
>
> --
> 2.21.0
--
- Arnaldo
next prev parent reply other threads:[~2019-05-31 12:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 8:03 [PATCH] perf jvmti: Fix gcc string overflow warning Jiri Olsa
2019-05-31 12:05 ` Arnaldo Carvalho de Melo [this message]
2019-05-31 13:13 ` [PATCHv2] " Jiri Olsa
2019-06-05 12:53 ` Arnaldo Carvalho de Melo
2019-06-17 19:15 ` [tip:perf/core] perf jvmti: Address gcc string overflow warning for strncpy() tip-bot for Jiri Olsa
2019-07-09 11:33 ` tip-bot for Jiri Olsa
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=20190531120530.GB17152@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=alexander.shishkin@linux.intel.com \
--cc=ben.gainey@arm.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.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.