linux-kernel - Re: [PATCH v1 0/5] soc/arm64: qcom: add initial version of memory dump

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]

Date:   Mon, 23 Oct 2023 15:50:03 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Zhenhua Huang <quic_zhenhuah@...cinc.com>, agross@...nel.org,
        andersson@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org
Cc:     linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...cinc.com,
        quic_tingweiz@...cinc.com
Subject: Re: [PATCH v1 0/5] soc/arm64: qcom: add initial version of memory
 dump

On 23.10.2023 11:20, Zhenhua Huang wrote:
> Qualcomm memory dump driver is to cooperate with firmware, providing the
Firmware == The hypervisor? The TZ? Some uncore chip?

> hints(id and size) of storing useful debugging information into pre-allocated
> memory. Firmware then does the real data capture. The debugging information
> includes cache contents, internal memory, registers. 
Exposing all of the user's data.. Is this enabled by default?

> 
> The driver dynamically reserves memory and provides the hints(dump id and size)
> following specified protocols with firmware. After crash and warm reboot,
> firmware scans these information and stores contents into reserved memory
> accordingly. Firmware then enters into full dump mode which dumps whole DDR
> to host through USB.
Is that only something that works on engineering / prototype devices?

> User then get full dump using PCAT and can parse out these informations.
Is PCAT open-source, or at least freely available?

> 
> Dump id and size are provided by bootconfig. The expected format of a
> bootconfig file is as follows:-
Is it the same bootconfig that Google invented? Wasn't that just key=val?

> memory_dump_config {
> 	<node name> {
> 		id = <id of HW component>
> 		size = <dump size of HW component>
> 	}
> }
> 
> for example:
> memory_dump_config {
>         c0_context_dump {
> 		id = 0
> 		size = 0x800
>         }
> }
> 
> Test based on 6.6-rc1.
That's sorta ancient, especially since you're likely looking to get
this merged in 6.8.. -next would probably be a better target.

Konrad