linux-kernel - Re: [PATCH] arm64: dts: qcom: sa8775p: add symbols to dtb

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] [day] [month] [year] [list]

Message-ID: <20230324171909.t6hhuwzduypj5b5b@echanude>
Date:   Fri, 24 Mar 2023 13:19:09 -0400
From:   Eric Chanudet <echanude@...hat.com>
To:     Bjorn Andersson <andersson@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Prasad Sodagudi <quic_psodagud@...cinc.com>
Subject: Re: [PATCH] arm64: dts: qcom: sa8775p: add symbols to dtb

On Tue, Mar 21, 2023 at 07:55:19PM -0700, Bjorn Andersson wrote:
> On Thu, Mar 09, 2023 at 06:39:48PM -0500, Eric Chanudet wrote:
> > ABL uses the __symbols__ section to process the DTB before passing it
> > forward. Without it, the bootstrap is interrupted.
> > 
> 
> If the reason is that ABL refuses to boot without it, then please have
> ABL fixed. If on the other hand there is a valid reason for ABL to
> require the dtb to have __symbols__ defined, please describe that - if
> nothing else so that others know when this is supposed to be used.

Here is what I understand from the ABL sources and discussions with
Prasad:

Android Boot Loader (ABL), the UEFI application to run before executing
the kernel, implements the Qualcomm SCM protocol to call into TZ. One of
these SCM call is trapped by the hypervisor, itself provided with the
firmware package for the board, and returns to ABL some information
about our VM. These information may include one or more DTBO. ABL then
proceeds and tries to apply the overlays on the DTB it loaded from the
Android Boot Image it is trying to boot.

If there is an hypervisor and it returned at least one DTBO, ABL treats
a failure to apply the DTBO (e.g, if __symbols__ are not available in
the DTB) as critical and ends the boot. I was only ever given a firmware
package that included the hypervisor and it always returned at least one
DTBO. So enabling overlays is required to run this board, using the
firmware I know of, with an upstream kernel and DTB at time of writing.

I suppose ABL could be made to handle such failure as a warning and
continue booting? Which comes down to ignoring the DTBO provided by the
hypervisor. Maybe that still allows the kernel to run the board with
limited functionality?

Prior cases in the git history for enabling overlays covered board
variants and extension headers (ti and nvidia). These do not fit what is
happening here. In hindsight, I should have sent this as an RFC, with
the above explanation to begin with, to ask about the limits and
requirements.

Maybe Prasad, or someone with a more comprehensive knowledge of this
board, can fill the remaining gaps or correct my understanding of the
boot sequence if I got something wrong?

Thanks,

-- 
Eric Chanudet