linux-kernel - Re: [PATCH 05/11] dt-bindings: document the Qualcomm TEE Shared Memory Bridge

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: <CACMJSeuOigO38_jgjNLz6AiWK1BoLN+shDQHrubS5s-dkDFG7A@mail.gmail.com>
Date:   Wed, 30 Aug 2023 15:48:41 +0200
From:   Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Alex Elder <elder@...aro.org>,
        Srini Kandagatla <srinivas.kandagatla@...aro.org>,
        kernel@...cinc.com, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 05/11] dt-bindings: document the Qualcomm TEE Shared
 Memory Bridge

On Tue, 29 Aug 2023 at 11:30, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>
> On 29.08.2023 10:02, Krzysztof Kozlowski wrote:
> > On 28/08/2023 21:25, Bartosz Golaszewski wrote:
> >> Add Device Tree bindings for Qualcomm TEE Shared Memory Brige - a
> >> mechanism that allows sharing memory buffers between trustzone and the
> >> kernel.
> >
> > Subject prefix:
> > dt-bindings: firmware:
> >
> >
> >
> >>
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >> ---
> >>  .../bindings/firmware/qcom,shm-bridge.yaml    | 36 +++++++++++++++++++
> >>  1 file changed, 36 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml b/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml
> >> new file mode 100644
> >> index 000000000000..f660962b7b86
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml
> >> @@ -0,0 +1,36 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/firmware/qcom,shm-bridge.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: QCOM Shared Memory Bridge
> >> +
> >> +description: |
> >
> > Do not need '|' unless you need to preserve formatting.
> >
> >> +  Qualcomm TEE Shared Memory Bridge allows sharing limited areas of kernel's
> >> +  virtual memory with the trustzone in order to avoid mapping the entire RAM.
> >> +
> >> +maintainers:
> >> +  - Bjorn Andersson <andersson@...nel.org>
> >> +  - Konrad Dybcio <konrad.dybcio@...aro.org>
> >> +  - Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >> +
> >> +properties:
> >> +  compatible:
> >> +    items:
> >> +      - enum:
> >> +          - qcom,shm-bridge-sa8775p
> >> +          - qcom,shm-bridge-sm8150
> >> +          - qcom,shm-bridge-sm8450
> >> +      - const: qcom,shm-bridge
> >> +
> >
> > Looks quite empty... Why this cannot be part of qcom,scm? IOW, why do
> > you need new binding if you do not have any resources here and the block
> > is essentially feature of qcom,scm firmware?
> Since it's "discoverable" (via retval of an scm call), I'd second the
> idea of probing this from within the SCM driver.
>
> Konrad

Downstream has a bunch of DT switches that we don't support for now
upstream. I disagree about shoehorning this into the SCM driver. It
really is a layer on top of SCM but also SCM is a user of this
interface.

I will send a v2 with QCom ICE as a second user so that exporting
symbols pointed out by Krzysztof as having no users make more sense.
Hopefully keeping it separate will make more sense too.

If anything, the SHM Bridge code should stay in a separate compilation
unit even as part of SCM.

Bart