Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Stephen Brennan <stephen.s.brennan@oracle.com>
To:     Baoquan He <bhe@redhat.com>
Cc:     linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
        akpm@linux-foundation.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
In-Reply-To: <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv>
References: <20220517000508.777145-1-stephen.s.brennan@oracle.com>
 <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv>
Date:   Mon, 23 May 2022 11:00:55 -0700
Message-ID: <878rqs163s.fsf@stepbren-lnx.us.oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zEMbj1rol3TqUBCfsD3wZ/EWqS8rR/pOp3UqrYwdtfdBAVww7CgRPqUSm4fF?=
 =?us-ascii?Q?vYLvMZjSVsUGT6RusXhL4vh92iNY+k2YDGP/5LAbhzdX82eViMwbDcwryZE3?=
 =?us-ascii?Q?DxA+PmfErsfjsQLUCeb5Cij7CSsOBWFqykQmN3tGLZWPQYljRz991uwQAa90?=
 =?us-ascii?Q?GK947P5M6Vzoi99YPHkijwZxIS0x/b8tmV1/gouNToA2yW+39TLR6kMRXmm2?=
 =?us-ascii?Q?N5Xtzt2TPmZWr2srTQWwgnJqx1a5FxrBY+XKafhODSW+NTmvHS8iplHrzL7T?=
 =?us-ascii?Q?Hhi03J9Ux8LWAi14ldRbuSx9dWOMKVouOlHT21eDFa+5wkuqRBYeJ5VeuBjg?=
 =?us-ascii?Q?M3p4wbITpRp1VYVq7XEfGzRxaPDKWRQmkIGY088r+plCDPeMvOzCUWx8VlTe?=
 =?us-ascii?Q?D6QncH8yKO1aO1dyXIRh8IpLAtOsGtuaMFTicEg4qgKbkz5MGs/2DiyqtIaI?=
 =?us-ascii?Q?OVUSEZvP9I/zw9fQffg9441wXfx/89hqA7kxJLMk4Z6I5py55GkY2OBiqXkb?=
 =?us-ascii?Q?Ig6a5Sf03asu3mTGwJXnd+dIHL61G8+8Tn23C1GaAOMKfDqsu8u074oSQMkP?=
 =?us-ascii?Q?4c4MtpepZHygGqJxikoLCBFWUKQCw46rHnbD4C0VDvGjiPi+pneOMPlhpvUQ?=
 =?us-ascii?Q?ksUKp57Qexjigb0KN9xKP+81BCfR6Z47uSsf51slgcqepTIk9dICAzMccwGh?=
 =?us-ascii?Q?L3qrXWcdlxWLwV+ACiiK8Fka2TCOe2Ju0OHvluFS0XrGAtzUjiLSzI8rsSfE?=
 =?us-ascii?Q?sL+QZhYDS9fWups3VLxG16g0qSQvdLxpwFJLj9f2amKphioCV2wcUq1W8SR5?=
 =?us-ascii?Q?RkOg4gvnA6A3Cj4aqhhlZ28zS2E5VIPe8Q1apn5URk3tKALNruvSPAgP/Ezw?=
 =?us-ascii?Q?Atz2B1OTdHN7CCpvWZIm0s9ZFTJyuHrnmp+kaFYfgqOTbvXY78Zjn0Y0XLv7?=
 =?us-ascii?Q?/aU4aE7eHmzNNYbC8+YpcqGE4oR330qP7vwmA9G+j1EPHQmBGAEiggn0BrHw?=
 =?us-ascii?Q?UNlvsmde6i7sm1R9u3JThyc8pI7Q1aWdvGpTb4DHP/9bTWDaUq/sIEgBIX2/?=
 =?us-ascii?Q?b8vk3s6Kt176zL9qsJEsFm0gj2l7wdnFeh5Egv2+zwrcPjbKnab/00yZoXJc?=
 =?us-ascii?Q?BUFzJUEhfKxUn/AVVFVfqhn3FcU645Ad0DafutRU/wzv1DvM7FnyPJYLxL1Z?=
 =?us-ascii?Q?+k/GkrS0lPu25j9wyPc/FTbpt4J6+OvuvThS0pSgFpoLhgxiPeIrGrixlMAY?=
 =?us-ascii?Q?rQwEIosQVe2GjqKyJzLJZSWcJJ2mx72QLs0S/IB5xpNEJFMxyQM0V6IFREfk?=
 =?us-ascii?Q?isEX0Gn+bZjFg/Sk3E+0Gi7qMhEizS3mNUL/RJfes6nkjfEAXYxOqktmwXWv?=
 =?us-ascii?Q?AMTTG3FixvsruU+r/bCDVSO2cggjKvdLcjOcGDwV5ktiAbxzfcIBOUMJtUcm?=
 =?us-ascii?Q?LJ49KCuMocwmLEyqECLSnEQG0YyZbZA8JacfEiXoNzWFpnJI4do2lPWRQcl7?=
 =?us-ascii?Q?3nomKX5eUxgewxIWDYPTorvvrptfhuMBbGywY46ZmoQyeUqC6buM4XhRlTxf?=
 =?us-ascii?Q?8hShJrvJ4BfEQxKCTK+W0+1S3B5Z3GTI+GX2nfOl1daXSP8fEvC6k06P9KdI?=
 =?us-ascii?Q?6KfAd4k5WEP9gvNREP+bm1Xaa9HVXWe4NkNOju+lX63yrnZ1MJxLUVgG1q5F?=
 =?us-ascii?Q?xwA46GmH2CjPV4/6dL6XxtHwum4OUTC1gKuLB4jL+RKabbkibTi+DrXxrUsc?=
 =?us-ascii?Q?4cT1mpZWYYpYThoQiO0a6PCXoT99Vlw=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 549f65b0-227d-4a31-4a80-08da3ce63015
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4166.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2022 18:00:57.5067
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NZy2gPd3ufjKYnm3vKITdTotC9Sl1bIa0qRtZ6NQa5KBimVafKjQkaMRSrSZaxlHrcbd+9Xb5tcXgq2GxlNnXKV1kRpIlrKZqfzcrtyoREw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB2987
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-23_07:2022-05-23,2022-05-23 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxscore=0
 phishscore=0 mlxlogscore=727 adultscore=0 malwarescore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2205230102
X-Proofpoint-ORIG-GUID: SaL7w5T4TTy9ucPjoJ8StLRLAPN622um
X-Proofpoint-GUID: SaL7w5T4TTy9ucPjoJ8StLRLAPN622um
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?

Thanks,
Stephen