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]

Message-ID: <ac42f27e-007d-1157-ae46-403420d9fdcb@quicinc.com>
Date:   Tue, 24 Oct 2023 18:10:54 +0800
From:   Zhenhua Huang <quic_zhenhuah@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>, <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 2023/10/23 21:50, Konrad Dybcio wrote:
> 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?

It's part of bootloader which also needs to cooperate with TZ. After 
system crash and warm reset, system enters debug mode which needs the 
dump table.

> 
>> 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?

In theory it can be controlled by static bool download_mode = 
IS_ENABLED(CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT); in driver qcom_scm.c.
But from my local test on RB5, it can always enter into download mode seems.

> 
>>
>> 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?

I see it is introduced in doc of development-kit for RB5, but in another 
mail Caleb mentioned it's still needing to sign up... which I need to 
further investigate.

> 
>>
>> 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?

Seems not same, the author is not from google :) it's kernel XBC(extra 
boot config): lib/bootconfig.c

> 
>> 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.

Sure, Thanks. Will verify in -next.

> 
> Konrad

Thanks,
Zhenhua