From: Yonghong Song <yhs@fb.com>
To: Daniel Borkmann <daniel@iogearbox.net>, <ast@kernel.org>
Cc: <bpf@vger.kernel.org>, <netdev@vger.kernel.org>,
<torvalds@linux-foundation.org>, <mhiramat@kernel.org>,
<brendan.d.gregg@gmail.com>, <hch@lst.de>,
<john.fastabend@gmail.com>
Subject: Re: [PATCH bpf 3/3] bpf: restrict bpf_trace_printk()'s %s usage and add %psK, %psU specifier
Date: Thu, 14 May 2020 11:10:32 -0700 [thread overview]
Message-ID: <34e9da6e-1f1e-30c2-5863-55f7d8506eb8@fb.com> (raw)
In-Reply-To: <20200514161607.9212-4-daniel@iogearbox.net>
On 5/14/20 9:16 AM, Daniel Borkmann wrote:
> Usage of plain %s conversion specifier in bpf_trace_printk() suffers from the
> very same issue as bpf_probe_read{,str}() helpers, that is, it is broken on
> archs with overlapping address ranges.
>
> While the helpers have been addressed through work in 6ae08ae3dea2 ("bpf: Add
> probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers"), we need
> an option for bpf_trace_printk() as well to fix it.
>
> Similarly as with the helpers, force users to make an explicit choice by adding
> %psK and %psU specifier to bpf_trace_printk() which will then pick the corresponding
> strncpy_from_unsafe*() variant to perform the access under KERNEL_DS or USER_DS.
In bpf_trace_printk(), we only print strings.
In bpf-next bpf_iter bpf_seq_printf() helper, introduced by
commit 492e639f0c22 ("bpf: Add bpf_seq_printf and bpf_seq_write
helpers"), print strings and ip addresses %p{i,I}{4,6}.
Alan in
https://lore.kernel.org/bpf/alpine.LRH.2.21.2005141738050.23867@localhost/T
proposed BTF based type printing with a new format specifier
%pT, which potentially will be used in bpf_trace_printk() and
bpf_seq_printf().
In the future, we may want to support more %p<...> format in these
helpers. I am wondering whether we can have generic way so we only need
to change lib/vsprintf.c once.
Maybe using %pk<...> to specify the kernel address and %pu<...> to
specify user address space. In the above example, we will have
%pks, %pus, %pki4 or %pui4, etc. Does this make sense?
>
> Existing %s for legacy users is still kept working for archs where it is not
> broken and therefore gated through CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE.
>
> Fixes: 8d3b7dce8622 ("bpf: add support for %s specifier to bpf_trace_printk()")
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Reported-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
> Cc: Christoph Hellwig <hch@lst.de>
> ---
> Documentation/core-api/printk-formats.rst | 14 ++++
> kernel/trace/bpf_trace.c | 92 +++++++++++++++--------
> lib/vsprintf.c | 7 +-
> 3 files changed, 81 insertions(+), 32 deletions(-)
>
> diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..76b5f4f265cb 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -112,6 +112,20 @@ used when printing stack backtraces. The specifier takes into
> consideration the effect of compiler optimisations which may occur
> when tail-calls are used and marked with the noreturn GCC attribute.
>
> +Probed Strings from BPF
> +-----------------------
> +
> +::
> +
> + %psK kernel_string
> + %psU user_string
> +
> +The ``sK`` and ``sU`` specifiers are used for printing a string from probed
> +memory. From regular vsnprintf(), they are equivalent to ``%s``, however,
> +when used out of BPF's bpf_trace_printk() it reads a string of up to 64 bytes
> +in memory without faulting. For ``K`` specifier, the string is probed out of
> +kernel memory whereas for ``U`` specifier, it is probed out of user memory.
> +
> Kernel Pointers
> ---------------
>
[...]
next prev parent reply other threads:[~2020-05-14 18:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 16:16 [PATCH bpf 0/3] Restrict bpf_probe_read{,str}() and bpf_trace_printk()'s %s Daniel Borkmann
2020-05-14 16:16 ` [PATCH bpf 1/3] bpf: restrict bpf_probe_read{,str}() only to archs where they work Daniel Borkmann
2020-05-14 18:57 ` Linus Torvalds
2020-05-15 0:06 ` Masami Hiramatsu
2020-05-14 16:16 ` [PATCH bpf 2/3] bpf: add bpf_probe_read_{user, kernel}_str() to do_refine_retval_range Daniel Borkmann
2020-05-14 16:22 ` John Fastabend
2020-05-14 17:41 ` Yonghong Song
2020-05-14 16:16 ` [PATCH bpf 3/3] bpf: restrict bpf_trace_printk()'s %s usage and add %psK, %psU specifier Daniel Borkmann
2020-05-14 18:10 ` Yonghong Song [this message]
2020-05-14 21:05 ` Daniel Borkmann
2020-05-14 16:58 ` [PATCH bpf 0/3] Restrict bpf_probe_read{,str}() and bpf_trace_printk()'s %s Christoph Hellwig
2020-05-14 19:54 ` Daniel Borkmann
2020-05-14 19:58 ` Christoph Hellwig
2020-05-14 21:10 ` Daniel Borkmann
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=34e9da6e-1f1e-30c2-5863-55f7d8506eb8@fb.com \
--to=yhs@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=daniel@iogearbox.net \
--cc=hch@lst.de \
--cc=john.fastabend@gmail.com \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).