[PATCH 0/2] Expose kallsyms data in vmcoreinfo note

Stephen Brennan stephen.s.brennan at oracle.com
Mon May 23 11:00:55 PDT 2022


Baoquan He <bhe at redhat.com> writes:
> 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 at redhat.com>

Thanks Baoquan! I don't believe we have any worries regarding security,
since the kallsyms data itself is already available to root via
/proc/kallsyms, and core dumps should already be treated as highly
sensitive data by anybody handling them.

Do you know which tree this patch will go through?

Thanks,
Stephen



More information about the kexec mailing list