linux-kernel - Re: [RFC PATCH 0/6] Add basic Minidump kernel driver 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]

Date:   Mon, 27 Feb 2023 15:45:31 +0530
From:   Mukesh Ojha <quic_mojha@...cinc.com>
To:     Brian Masney <bmasney@...hat.com>
CC:     <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <keescook@...omium.org>,
        <tony.luck@...el.com>, <gpiccoli@...lia.com>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <linux-arm-msm@...r.kernel.org>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-hardening@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/6] Add basic Minidump kernel driver support



On 2/25/2023 12:36 AM, Brian Masney wrote:
> Hi Mukesh,
> 
> On Fri, Feb 24, 2023 at 04:10:42PM +0530, Mukesh Ojha wrote:
>> On 2/23/2023 6:07 PM, Brian Masney wrote:
>>> I'd like to test this series plus your series that sets the multiple
>>> download modes.
>>
>> Sure, you are welcome, but for that you need a device running with Qualcomm
>> SoC and if it has a upstream support.
> 
> I will be testing this series on a sa8540p (QDrive3 Automotive
> Development Board), which has the sc8280xp SoC with good upstream
> support. This is also the same board that I have a reliable way to
> make the board crash due to a known firmware bug.
> 


Can you try below patch to just select minidump download mode and make 
the device crash ?

--------------------------------------->8-------------------------------
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi 
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 0d02599..bd8e1a8 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -280,6 +280,7 @@
         firmware {
                 scm: scm {
                         compatible = "qcom,scm-sc8280xp", "qcom,scm";
+                       qcom,dload-mode = <&tcsr 0x13000>;
                 };
         };

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index cdbfe54..e1539a2 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -20,7 +20,7 @@

  #include "qcom_scm.h"

-static bool download_mode = 
IS_ENABLED(CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT);
+static bool download_mode = true;
  module_param(download_mode, bool, 0);

  #define SCM_HAS_CORE_CLK       BIT(0)
@@ -427,7 +427,7 @@ static void qcom_scm_set_download_mode(bool enable)
                 ret = __qcom_scm_set_dload_mode(__scm->dev, enable);
         } else if (__scm->dload_mode_addr) {
                 ret = qcom_scm_io_writel(__scm->dload_mode_addr,
-                               enable ? QCOM_SCM_BOOT_SET_DLOAD_MODE : 0);
+                               enable ? 0x20 : 0);
         } else {
                 dev_err(__scm->dev,
                         "No available mechanism for setting download 
mode\n");




>> Also, testing of this patch needs some minimal out of tree patches and
>> i can help you with that.
> 
> Yup, that's fine. Hopefully we can also work to get those dependencies
> merged upstream as well.
> 
> Brian
>