linux-kernel - Re: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Jun 2022 14:26:09 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Stephen Brennan <stephen.s.brennan@...cle.com>
Cc:     Baoquan He <bhe@...hat.com>, linux-kernel@...r.kernel.org,
        kexec@...ts.infradead.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Dave Young <dyoung@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Bixuan Cui <cuibixuan@...wei.com>,
        David Vernet <void@...ifault.com>,
        Vivek Goyal <vgoyal@...hat.com>,
        Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note

On Mon, 16 May 2022 17:05:06 -0700 Stephen Brennan <stephen.s.brennan@...cle.com> wrote:

> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to navigate a core dump or live system, but they need
> to be able to find it.
> 
> This patch series adds the necessary symbols into vmcoreinfo, which
> would allow a debugger to find and interpret the kallsyms table. Using
> the kallsyms data, the debugger can then lookup any symbol, allowing it
> to find ORC, BTF, or any other useful data.
> 
> This would allow a live kernel, or core dump, to be debugged without
> any DWARF debuginfo. This is useful for many cases: the debuginfo may
> not have been generated, or you may not want to deploy the large files
> everywhere you need them.

Am trying to understand the value of all of this.  Can you explain
further why carrying the dwarf info is problematic?  How problematic
are these large files?

> I've demonstrated a proof of concept for this at LSF/MM+BPF during a
> lighting talk. Using a work-in-progress branch of the drgn debugger, and
> an extended set of BTF generated by a patched version of dwarves, I've
> been able to open a core dump without any DWARF info and do basic tasks
> such as enumerating slab caches, block devices, tasks, and doing
> backtraces. I hope this series can be a first step toward a new
> possibility of "DWARFless debugging".
> 
> Related discussion around the BTF side of this:
> https://lore.kernel.org/bpf/586a6288-704a-f7a7-b256-e18a675927df@oracle.com/T/#u
> 
> Some work-in-progress branches using this feature:
> https://github.com/brenns10/dwarves/tree/remove_percpu_restriction_1
> https://github.com/brenns10/drgn/tree/kallsyms_plus_btf

What's the story on using gdb with this?