Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 25 May 2022 10:39:26 +0800
From:   Baoquan He <bhe@redhat.com>
To:     Stephen Brennan <stephen.s.brennan@oracle.com>,
        akpm@linux-foundation.org
Cc:     linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
        Nick Desaulniers <ndesaulniers@google.com>,
        Dave Young <dyoung@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Jiri Olsa <jolsa@kernel.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Bixuan Cui <cuibixuan@huawei.com>,
        David Vernet <void@manifault.com>,
        Vivek Goyal <vgoyal@redhat.com>,
        Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note
Message-ID: <Yo2W3mH/5uuAJyw5@MiWiFi-R3L-srv>
References: <20220517000508.777145-1-stephen.s.brennan@oracle.com>
 <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv>
 <878rqs163s.fsf@stepbren-lnx.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <878rqs163s.fsf@stepbren-lnx.us.oracle.com>
Precedence: bulk

On 05/23/22 at 11:00am, Stephen Brennan wrote:
> Baoquan He <bhe@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@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?

I would like to ask Andrew to help check and pick this if no concern.

Thanks
Baoquan