linux-kernel - Re: RESEND: Re: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide

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: <CADHLONEn4oyRFrNWEbt2mxMczyc8FrDLMzaZ7fsijzm9Y8VTBA@mail.gmail.com>
Date: Mon, 8 Jan 2024 23:34:50 +0800
From: Ruipeng Qi <ruipengqi7@...il.com>
To: Mukesh Ojha <quic_mojha@...cinc.com>
Cc: agross@...nel.org, alim.akhtar@...sung.com, andersson@...nel.org, 
	bmasney@...hat.com, conor+dt@...nel.org, corbet@....net, gpiccoli@...lia.com, 
	keescook@...omium.org, kernel@...cinc.com, kgene@...nel.org, 
	konrad.dybcio@...aro.org, krzysztof.kozlowski+dt@...aro.org, 
	linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-hardening@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org, 
	linux-remoteproc@...r.kernel.org, linux-samsung-soc@...r.kernel.org, 
	mathieu.poirier@...aro.org, matthias.bgg@...il.com, nm@...com, 
	robh+dt@...nel.org, tony.luck@...el.com, vigneshr@...com, 
	qiruipeng@...iang.com
Subject: Re: RESEND: Re: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide

On Wed, Jan 3, 2024 at 11:27 PM Mukesh Ojha <quic_mojha@...cinc.com> wrote:
>
>
> One more thing, kernel part of minidump, we are calling it APSS Minidump
> has limitation of no of entries so it will be difficult to dump
> non-continuous regions after a certain number of registration ~200. However,
> we do have a solution in downstream kernel for it like to create a big
> CMA buffer and register this buffer with Minidump so that whatever gets
> dumped in that buffer gets captured during crash and fill up this buffer
> and create elf during panic. I think, similar thing you are also doing
> with your OS-minidump.
>
> I have just glanced into your implementation of OS-minidump, it
> more of relying on basic concept of RAM content preserved
> across boot and later reading it through procfs but this basic
> stuff is common to pstore(ram) as well and pstore has file system
> support why don't you make your driver as one of pstore record and that
> way Qualcomm minidump also gets benefited where entire OS-minidump
> record gets registered with Qualcomm minidump and we get this on panic
> and you get this via pstorefs.
>
Thanks Mukesh！It is a good suggestion to move OS-minidump forward!
By the way, I have some questions here for which I need your assistance.

Firstly,I can reimplement OS-minidump as one of the pstore records to
dump data. The resulting dump file would contain thousands of
non-contiguous memory regions, each with only the virtual address and
size recorded. As far as I know, Qualcomm's minidump can handle
several memory regions, each with a physical address and size.
This seems to be a difference, and I'm curious as to how you deal with
data dumped by OS-minidump. I would really appreciate it if you could
provide more details on your approach.

Secondly, what tools do you use to analyze the dump data, and does it
support crash tool?

Lastly, is Qualcomm minidump compatible with non-Qualcomm SoCs,
and if so, how can one use it?

Best Regards
Ruipeng Qi