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]

Message-ID: <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv>
Date:   Wed, 18 May 2022 18:19:28 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Stephen Brennan <stephen.s.brennan@...cle.com>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        akpm@...ux-foundation.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 05/16/22 at 05:05pm, Stephen Brennan 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.
> 
> 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".

Thanks. Seems no reason to reject, even though I haven't tried drgn.
And hope it has no security issue, e.g info leakage, at least I don't
see it has. So,

Acked-by: Baoquan He <bhe@...hat.com>