linux-kernel - [PATCH RFC 0/2] mailbox: tmelite-qmp: Introduce QCOM TMEL QMP mailbox driver

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

Message-ID: <20241205080633.2623142-1-quic_srichara@quicinc.com>
Date: Thu, 5 Dec 2024 13:36:31 +0530
From: Sricharan R <quic_srichara@...cinc.com>
To: <jassisinghbrar@...il.com>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <quic_srichara@...cinc.com>
Subject: [PATCH RFC 0/2] mailbox: tmelite-qmp: Introduce QCOM TMEL QMP mailbox driver

From: Sricharan Ramabadhran <quic_srichara@...cinc.com>

The QMP mailbox is the primary means of communication between TME-L SS
and other subsystem on the SoC. A dedicated pair of inbound and outbound
mailboxes is implemented for each subsystem/external execution environment
which needs to communicate with TME-L for security services. The inbound
mailboxes are used to send IPC requests to TME-L, which are then processed
by TME-L firmware and accordingly the responses are sent to the requestor
via outbound mailboxes.

It is an IPC transport protocol which is light weight and supports
a subset of API's. It handles link initialization, negotiation,
establishment and communication across client(APPSS/BTSS/AUDIOSS)
and server(TME-L SS).

   -----------------------------------------------       ---------------------------------------------------
  |                                              |       |                                                 |
  |                 SOC  CLIENT                  | SOC   |                TME-L  SS                        |
  |                                              | AHB   |                                                 |
  |     ----------    ---------   ---------      |       | ------    -------     --------    ------------  |
  |     |        |    |       |   |       |      | WO    | |     | R |     |     |      |    |SERVICES   | |
  |     | APPS   |<-->| TMEL  |<->|       |------------->| | IN  |-->|     |     | TMEL |    |--------   | |
  |     |        |    | COM   |   | QMP   |      | RO    | |     | W | QMP |<--->| COM  |<-->| a) ATTEST | |
  |     |        |    |       |   |       |<-------------| | OUT |<--|     |     |      |    | b) CRYPTO | |
  |     |        |    |       |   |       |      |       | |     |   |     |     |      |    | .. more   | |
  |     ---------     ---------   ---------      |       | ------    -------     -------     ------------  |
  |                                              |       |                                                 |
   -----------------------------------------------       --------------------------------------------------

TME-L SS provides different kinds of services like secureboot, remote image authentication,
key management, crypto, OEM provisioning etc. This patch adds support for remote image
authentication. Support for rest of the services can be added.

Remote proc driver subscribes to this mailbox and uses the mbox_send_message to use
TME-L to securely authenticate/teardown the images.

The intention of posting this is to get the design reviewed/corrected since there are also
other possible ways of having this SS support like:

a) Make TMEL QMP as a 'rpmsg' driver and clients can connect using rmpsg_send

b) Keep TMEL APIs seperately in drivers/firmware which would export APIs
   and QMP mailbox seperately.
   Clients can then call the exported APIS.

c) Combine both TMEL and QMP as mailbox (this is the approach used here)

Since clients like same rproc driver use SCM/TMEL across socs, the goal here was to abstract the
TMEL-QMP SS functionality, so that clients should be able to connect and send messages with
a common API.

Based on the feedback can explore any other options as well.

Sricharan Ramabadhran (2):
  dt-bindings: mailbox: Document qcom,tmelite-qmp
  mailbox: tmelite-qmp: Introduce TMEL QMP mailbox driver

 .../bindings/mailbox/qcom,tmelite-qmp.yaml    |  70 ++
 drivers/mailbox/Kconfig                       |   7 +
 drivers/mailbox/Makefile                      |   2 +
 drivers/mailbox/qcom-tmelite-qmp.c            | 949 ++++++++++++++++++
 include/linux/mailbox/tmelcom-qmp.h           | 157 +++
 5 files changed, 1185 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,tmelite-qmp.yaml
 create mode 100644 drivers/mailbox/qcom-tmelite-qmp.c
 create mode 100644 include/linux/mailbox/tmelcom-qmp.h

-- 
2.34.1