linux-kernel - Re: [PATCH v2 2/3] firmware: qcom: scm: Expose download-mode control

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:   Wed, 31 May 2017 15:10:07 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Mark Rutland <mark.rutland@....com>,
        David Brown <david.brown@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-soc@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/3] firmware: qcom: scm: Expose download-mode control

On Wed 31 May 12:31 PDT 2017, Rob Herring wrote:

> On Fri, May 26, 2017 at 11:33:07PM -0700, Bjorn Andersson wrote:
> > In order to aid post-mortem debugging the Qualcomm platforms provides a
> > "memory download mode", where the boot loader will provide an interface
> > for custom tools to "download" the content of RAM to a host machine.
> > 
> > The mode is triggered by writing a magic value somehwere in RAM, that is
> > read in the boot code path after a warm-restart. Two mechanism for
> > setting this magic value are supported in modern platforms; a direct SCM
> > call to enable the mode or through a secure io write of a magic value.
> > 
> > In order for a normal reboot not to trigger "download mode" the magic
> > must be cleared during a clean reboot.
> 
> This must be happening somewhere before the kernel is entered? Or 
> warm-restarts are not the norm?
> 

Not sure I'm getting what you're asking here.

We set the flag on boot and clear it on shutdown, that way the early
boot stages will be able to detect if the board restarted uncleanly -
e.g. from accessing a protected register.

> > Download mode has to be enabled by including qcom_scm.download_mode=1 on
> > the command line.
> 
> This looks similar to reboot reason functionality (i.e. boot into mode 
> X). I'd expect this to use that at least for the kernel. Not sure about 
> bindings though.
> 

It's very much like reboot reason except the small detail that we want
to enter this state when the board reboots without the kernels
knowledge.


Thinking about it, it may make sense to not clear the flag if we exit
through the panic handler. But if that's wanted it could be done in a
follow up patch, I only added this to catch an error where the RPM hit
its error handler and reboots the board.

Regards,
Bjorn