From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Brennan Date: Mon, 23 May 2022 11:00:55 -0700 Subject: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note In-Reply-To: References: <20220517000508.777145-1-stephen.s.brennan@oracle.com> Message-ID: <878rqs163s.fsf@stepbren-lnx.us.oracle.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org Baoquan He 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 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