linux-kernel - Re: [RFC PATCH v2 0/3] pmem memmap dump support

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: <774fd596-5481-aeff-aace-8785158728ea@fujitsu.com>
Date:   Mon, 8 May 2023 09:45:57 +0000
From:   "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Yasunori Gotou (Fujitsu)" <y-goto@...itsu.com>,
        "Xiao Yang (Fujitsu)" <yangx.jy@...itsu.com>,
        "Shiyang Ruan (Fujitsu)" <ruansy.fnst@...itsu.com>
Subject: Re: [RFC PATCH v2 0/3] pmem memmap dump support

Dan,


On 29/04/2023 02:59, Dan Williams wrote:
> Li Zhijian wrote:
>> Hello folks,
>>
>> About 2 months ago, we posted our first RFC[3] and received your kindly feedback. Thank you :)
>> Now, I'm back with the code.
>>
>> Currently, this RFC has already implemented to supported case D*. And the case A&B is disabled
>> deliberately in makedumpfile. It includes changes in 3 source code as below:
> 
> I think the reason this patchkit is difficult to follow is that it
> spends a lot of time describing a chosen solution, but not enough time
> describing the problem and the tradeoffs.
> 
> For example why is updating /proc/vmcore with pmem metadata the chosen
> solution? Why not leave the kernel out of it and have makedumpfile
> tooling aware of how to parse persistent memory namespace info-blocks
> and retrieve that dump itself? This is what I proposed here:
> 
> http://lore.kernel.org/r/641484f7ef780_a52e2940@dwillia2-mobl3.amr.corp.intel.com.notmuch

Sorry for the late reply. I'm just back from the vacation.
And sorry again for missing your previous *important* information in V1.

Your proposal also sounds to me with less kernel changes, but more ndctl coupling with makedumpfile tools.
In my current understanding, it will includes following source changes.

-----------+-------------------------------------------------------------------+
Source     |                      changes                                      |
-----------+-------------------------------------------------------------------+
I.         | 1. enter force_raw in kdump kernel automatically(avoid metadata being updated again)|
kernel     |                                                                   |
            | 2. mark the whole pmem's PT_LOAD for kexec_file_load(2) syscall   |
-----------+-------------------------------------------------------------------+
II. kexec- | 1. mark the whole pmem's PT_LOAD for kexe_load(2) syscall         |
tool       |                                                                   |
-----------+-------------------------------------------------------------------+
III.       | 1. parse the infoblock and calculate the boundaries of userdata and metadata   |
makedump-  | 2. skip pmem userdata region                                      |
file       | 3. exclude pmem metadata region if needed                         |
-----------+-------------------------------------------------------------------+

I will try rewrite it with your proposal ASAP

Thanks again

Thanks
Zhijian

> 
> ...but never got an answer, or I missed the answer.