From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
John Fastabend <john.fastabend@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
Petr Mladek <pmladek@suse.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-modules@vger.kernel.org
Subject: Re: [PATCH] [v3] kallsyms: rework symbol lookup return codes
Date: Wed, 26 Jul 2023 15:43:17 -0700 [thread overview]
Message-ID: <202307261536.797610DC@keescook> (raw)
In-Reply-To: <20230726141333.3992790-1-arnd@kernel.org>
On Wed, Jul 26, 2023 at 04:12:23PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Building with W=1 in some configurations produces a false positive
> warning for kallsyms:
>
> kernel/kallsyms.c: In function '__sprint_symbol.isra':
> kernel/kallsyms.c:503:17: error: 'strcpy' source argument is the same as destination [-Werror=restrict]
> 503 | strcpy(buffer, name);
> | ^~~~~~~~~~~~~~~~~~~~
>
> This originally showed up while building with -O3, but later started
> happening in other configurations as well, depending on inlining
> decisions. The underlying issue is that the local 'name' variable is
> always initialized to the be the same as 'buffer' in the called functions
> that fill the buffer, which gcc notices while inlining, though it could
> see that the address check always skips the copy.
>
> The calling conventions here are rather unusual, as all of the internal
> lookup functions (bpf_address_lookup, ftrace_mod_address_lookup,
> ftrace_func_address_lookup, module_address_lookup and
> kallsyms_lookup_buildid) already use the provided buffer and either return
> the address of that buffer to indicate success, or NULL for failure,
> but the callers are written to also expect an arbitrary other buffer
> to be returned.
>
> Rework the calling conventions to return the length of the filled buffer
> instead of its address, which is simpler and easier to follow as well
> as avoiding the warning. Leave only the kallsyms_lookup() calling conventions
> unchanged, since that is called from 16 different functions and
> adapting this would be a much bigger change.
>
> Link: https://lore.kernel.org/all/20200107214042.855757-1-arnd@arndb.de/
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v3: use strscpy() instead of strlcpy()
Thank you! :) (Though see my notes below...)
> [...]
> @@ -344,13 +345,12 @@ const char *module_address_lookup(unsigned long addr,
> #endif
> }
>
> - ret = find_kallsyms_symbol(mod, addr, size, offset);
> - }
> - /* Make a copy in here where it's safe */
> - if (ret) {
> - strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
This -1 was to keep the buffer NUL-terminated.
> - ret = namebuf;
> + sym = find_kallsyms_symbol(mod, addr, size, offset);
> +
> + if (sym)
> + ret = strscpy(namebuf, sym, KSYM_NAME_LEN - 1);
This strscpy should use KSYM_NAME_LEN without the "- 1".
> }
> +
> preempt_enable();
>
-Kees
--
Kees Cook
next prev parent reply other threads:[~2023-07-26 22:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 14:12 [PATCH] [v3] kallsyms: rework symbol lookup return codes Arnd Bergmann
2023-07-26 22:43 ` Kees Cook [this message]
2023-08-16 19:04 ` Steven Rostedt
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=202307261536.797610DC@keescook \
--to=keescook@chromium.org \
--cc=andrii@kernel.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.lau@linux.dev \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.