From: Kees Cook <keescook@chromium.org>
To: Miguel Ojeda <ojeda@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
Jarkko Sakkinen <jarkko@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Wedson Almeida Filho <wedsonaf@google.com>
Subject: Re: [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols
Date: Sat, 7 May 2022 01:32:15 -0700 [thread overview]
Message-ID: <202205070122.B240F989@keescook> (raw)
In-Reply-To: <20220507052451.12890-18-ojeda@kernel.org>
On Sat, May 07, 2022 at 07:24:15AM +0200, Miguel Ojeda wrote:
> Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`)
> provide Rust v0 mangling support.
>
> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com>
> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> I would like to use this patch for discussing the demangling topic.
>
> The following discusses the different approaches we could take.
>
>
> # Leave demangling to userspace
>
> This is the easiest and less invasive approach, the one implemented
> by this patch.
>
> The `decode_stacktrace.sh` script is already needed to map
> the offsets to the source code. Therefore, we could also take
> the chance to demangle the symbols here.
>
> With this approach, we do not need to introduce any change in the
> `vsprintf` machinery and we minimize the risk of breaking user tools.
>
> Note that, if we take this approach, it is likely we want to ask
> for a minimum version of either of the tools (since there may be
> users of the script that do not have recent enough toolchains).
For the first in-tree Rust support, I think this is entirely the right
approach.
> # Demangling in kernelspace on-the-fly
Please no. :) I don't see a benefit compared to doing it at
compile-time.
> Furthermore, this approach (and the ones below) likely require adding
> a new `%p` specifier (or a new modifier to existing ones) if we do
> not want to affect non-backtrace uses of the `B`/`S` ones. Also,
> it is unclear whether we should write the demangled versions in an
> extra, different line or replace the real symbol -- we could be
> breaking user tools relying on parsing backtraces (e.g. our own
> `decode_stacktrace.sh`). For instance, they could be relying on
> having real symbols there, or may break due to e.g. spaces.
I may need some examples here for what you're thinking will cause
problems. Why a new specifier? Won't demangling just give us text? Is
the concern about breaking backtrace parsers that only understand C
symbols?
> # Demangling at compile-time
>
> This implies having kallsyms demangle all the Rust symbols.
>
> The size of this data is around the same order of magnitude of the
> non-demangled ones. However, this is notably more than the demangling
> code (see previous point), e.g. 120 KiB (uncompressed) in a
> small kernel.
It seems all of that would be in the build-time helper, not the kernel
image, though, so that seems better than run-time demangling.
> # Demangling at compile-time and substituting symbols by hashes
Nah; this is even less readable than the mangled symbols. :) I don't
think the symbol length should be a concern. (Though maybe there are
some crash parsers that we can buffer overflow!)
> scripts/decode_stacktrace.sh | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
next prev parent reply other threads:[~2022-05-07 8:32 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 5:23 [PATCH v6 00/23] Rust support Miguel Ojeda
2022-05-07 5:23 ` [PATCH v6 01/23] kallsyms: avoid hardcoding the buffer size Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 02/23] kallsyms: support "big" kernel symbols Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 03/23] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 04/23] kunit: take `kunit_assert` as `const` Miguel Ojeda
2022-05-12 19:01 ` Brendan Higgins
2022-05-07 5:24 ` [PATCH v6 05/23] rust: add C helpers Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 06/23] rust: add `compiler_builtins` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 07/23] rust: import upstream `alloc` crate Miguel Ojeda
2022-05-07 9:23 ` Kees Cook
2022-05-07 9:33 ` Miguel Ojeda
2022-05-07 17:06 ` Kees Cook
2022-05-07 17:30 ` Linus Torvalds
2022-05-07 19:34 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 08/23] rust: adapt `alloc` crate to the kernel Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 09/23] rust: add `build_error` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 10/23] rust: add `macros` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 11/23] rust: add `kernel` crate's `sync` module Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 12/23] rust: add `kernel` crate Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 13/23] rust: export generated symbols Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 14/23] vsprintf: add new `%pA` format specifier Miguel Ojeda
2022-05-07 8:19 ` Kees Cook
2022-05-07 9:35 ` Miguel Ojeda
2022-05-10 8:38 ` Petr Mladek
2022-05-10 10:45 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 15/23] scripts: add `rustdoc_test_{builder,gen}.py` scripts Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 16/23] scripts: add `generate_rust_analyzer.py` scripts Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols Miguel Ojeda
2022-05-07 8:32 ` Kees Cook [this message]
2022-05-07 10:21 ` Miguel Ojeda
2022-05-07 17:09 ` Kees Cook
2022-05-07 5:24 ` [PATCH v6 18/23] docs: add Rust documentation Miguel Ojeda
2022-05-07 8:15 ` Kees Cook
2022-05-07 8:45 ` Miguel Ojeda
2022-05-09 4:02 ` Akira Yokosawa
2022-05-09 10:41 ` Miguel Ojeda
2022-05-09 14:56 ` Akira Yokosawa
2022-05-09 22:37 ` Jonathan Corbet
2022-05-10 11:57 ` Miguel Ojeda
2022-05-09 22:32 ` Jonathan Corbet
2022-05-10 3:14 ` Gaelan Steele
2022-05-10 5:53 ` Josh Triplett
2022-05-11 13:49 ` Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 19/23] Kbuild: add Rust support Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 20/23] samples: add Rust examples Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 21/23] MAINTAINERS: Rust Miguel Ojeda
2022-05-07 8:06 ` Kees Cook
2022-05-07 5:24 ` [PATCH v6 22/23] [RFC] drivers: gpio: PrimeCell PL061 in Rust Miguel Ojeda
2022-05-07 5:24 ` [PATCH v6 23/23] [RFC] drivers: android: Binder IPC " Miguel Ojeda
2022-05-07 7:55 ` Kees Cook
2022-05-07 8:13 ` Greg Kroah-Hartman
2022-05-09 17:52 ` Todd Kjos
2022-05-07 8:06 ` [PATCH v6 00/23] Rust support Kees Cook
2022-05-08 18:06 ` Matthew Wilcox
2022-05-09 9:39 ` Wei Liu
2022-05-07 9:29 ` David Gow
2022-05-07 15:03 ` Miguel Ojeda
2022-05-10 4:44 ` David Gow
2022-05-10 11:36 ` Miguel Ojeda
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=202205070122.B240F989@keescook \
--to=keescook@chromium.org \
--cc=alex.gaynor@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wedsonaf@google.com \
/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).