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: <20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com>
Date: Wed, 5 Nov 2025 13:44:21 +0530
From: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
To: Bryan O'Donoghue <bod@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Subject: Re: [PATCH v6 00/14] Peripheral Image Loader support for Qualcomm
 SoCs running Linux host at EL2

On Tue, Nov 04, 2025 at 04:25:26PM +0000, Bryan O'Donoghue wrote:
> On 04/11/2025 07:35, Mukesh Ojha wrote:
> > In May 2025, we discussed the challenges at Linaro Connect 2025 [1]
> > related to Secure PAS remoteproc enablement when Linux is running at EL2
> > for Qualcomm SoCs.
> > 
> > [1] https://resources.linaro.org/en/resource/sF8jXifdb9V1mUefdbfafa
> > 
> > Below, is the summary of the discussion.
> > 
> > Qualcomm is working to enable remote processors on the SA8775p SoC with
> > a Linux host running at EL2. In doing so, it has encountered several
> > challenges related to how the remoteproc framework is handled when Linux
> > runs at EL1.
> > 
> > One of the main challenges arises from differences in how IOMMU
> > translation is currently managed on SoCs running the Qualcomm EL2
> > hypervisor (QHEE), where IOMMU translation for any device is entirely
> > owned by the hypervisor. Additionally, the firmware for remote
> > processors does not contain a resource table, which would typically
> > include the necessary IOMMU configuration settings.
> > 
> > Qualcomm SoCs running with QHEE (EL2) have been utilizing the Peripheral
> > Authentication Service (PAS) from TrustZone (TZ) firmware to securely
> > authenticate and reset remote processors via a single SMC call,
> > _auth_and_reset_. This call is first trapped by QHEE, which then invokes
> > TZ for authentication. Once authentication is complete, the call returns
> > to QHEE, which sets up the IOMMU translation scheme for the remote
> > processors and subsequently brings them out of reset. The design of the
> > Qualcomm EL2 hypervisor dictates that the Linux host OS running at EL1
> > is not permitted to configure IOMMU translation for remote processors,
> > and only a single-stage translation is configured.
> > 
> > To make the remote processor bring-up (PAS) sequence
> > hypervisor-independent, the auth_and_reset SMC call is now handled
> > entirely by TZ. However, the issue of IOMMU configuration remains
> > unresolved, for example a scenario, when KVM host at EL2 has no
> > knowledge of the remote processors’ IOMMU settings.  This is being
> > addressed by overlaying the IOMMU properties when the SoC runs a Linux
> > host at EL2. SMC call is being provided from the TrustZone firmware to
> > retrieve the resource table for a given subsystem.
> > 
> > There are also remote processors such as those for video, camera, and
> > graphics that do not use the remoteproc framework to manage their
> > lifecycle. Instead, they rely on the Qualcomm PAS service to
> > authenticate their firmware. These processors also need to be brought
> > out of reset when Linux is running at EL2. The client drivers for these
> > processors use the MDT loader function to load and authenticate
> > firmware. Similar to the Qualcomm remoteproc PAS driver, they also need
> > to retrieve the resource table, create a shared memory bridge
> > (shmbridge), and map the resources before bringing the processors out of
> > reset.
> > 
> > It is based on next-20251103 and tested on SA8775p which is now called
> > Lemans IOT platform and does not addresses DMA problem discussed at
> > [1] which is future scope of the series.
> > 
> > Changes in v6: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-0-d609ed766061@oss.qualcomm.com/
> >   - Added comments made by Bryan to save some cycles and added in 2/14
> >     which could change patch order.
> >   - Renamed qcom_scm_pas_context_init to devm_qcom_scm_pas_context_init()
> >   - Replaced devm_kzalloc with kzalloc for output_rt in scm function as
> >     remoteproc framework does not usage devm_ api for resource table
> >     pointer which is cause mem-abort issue start/stop test.
> >   - Removed union usage and redundant code from qcom_scm_pas_prep_and_init_image().
> > 
> > Changes in v5: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-0-de841623af3c@oss.qualcomm.com/
> >   - Replaced minitems with maxitems.
> >   - Addressed comments made by Bryan, Mani and Konrad.
> >   - Fixed some of highlighted issues in v4.
> >   - Added a new patch which removes qcom_mdt_pas_init() from exported
> >     symbol list.
> >   - Slight change in  v4's 5/12, so that it does use qcom_mdt_pas_load()
> >     directly while it should use in the commit where it gets introduced.
> >     Hence, reordered the patches a bit like v4 5/12 comes early before
> >     4/12.
> > 
> > Changes in v4: https://lore.kernel.org/lkml/20250921-kvm_rproc_pas-v3-0-458f09647920@oss.qualcomm.com/
> >   - Fixed kernel robot warning/errors.
> >   - Reworded some of the commit log, code comment as per suggestion from Bryan.
> >   - Added support of gpdsp0 and gpdsp1 and disabled iris node.
> >   - Add R-b tag to some of the reviewed patches.
> >   - Rename struct qcom_scm_pas_cxt to qcom_scm_pas_context.
> > 
> > Changes in v3: https://lore.kernel.org/lkml/20250819165447.4149674-1-mukesh.ojha@oss.qualcomm.com/
> >   - Dropped video subsystem enablement for now, could add it in future
> >     or on a separate series.
> 
> I specifically think it is the wrong thing to do, to drop video enablement
> from this series.

There is no dependency of this series on video enablement. The only
reason I included it in my initial series was that video or other
non-remoteproc subsystems would need to call the resource table SMC call
and map the resources. Since I have dropped video support have dropped
the the helper function too that parses and maps the resources in this
newer series, it is no longer required.

https://lore.kernel.org/lkml/20250819165447.4149674-9-mukesh.ojha@oss.qualcomm.com/

> 
> Its just papering over the cracks. The right thing to do is to have the
> technical disucssion and agree a way forward, not to drop things that feel
> too contentious.
> 
> What's really so contentious about
> 
> video-firmware {
> 	iommu data here
> };
> 
> As has been done with ChromeOS on venus thus far ?
> 
> All that has to be made is a case for it.

Since there was an objection to removing the Venus YAML from the Iris
YAML [1], we cannot use it. We had a few similar use cases as mentioned
here [2], and you were part of all the discussions and agreed to remove
the item that could take time [3]. Therefore, it seemed valid to drop it
for now. A new approach[4] for video to handle these kind of sceanario
has been posted.

[1]
https://lore.kernel.org/lkml/20250823155349.22344-2-krzysztof.kozlowski@linaro.org/

[2]
https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/T/#m9891945187671417f25f134097383b72aa7f47c2

[3]
https://lore.kernel.org/lkml/ad5a58a6-2545-4429-9388-e8ad84319570@linaro.org/


[4]
https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/

> 
> >   - Addressed most of the suggestion from Stephen and Bryan like some
> >     remoteproc code checking resource table presence or right error
> >     code propagation above the layer.
> >   - Added leman-el2 overlay file.
> >   - Added missed iommus binding which was missed last series.
> >   - Separated qcom_mdt_pas_load() patch and its usage.
> >   - Patch numbering got changed compared to last version
> > 
> > Changes in v2: https://lore.kernel.org/lkml/20241004212359.2263502-1-quic_mojha@quicinc.com/
> >   - A lot has changed from the V1 and a fresh look would be preferred.
> >   - Removed approach where device tree contain devmem resources in
> >     remoteproc node.
> >   - SHMbridge need to created for both carveout and metadata memory
> >     shared to TZ in a new way.
> >   - Now, resource table would be given by SMC call which need to mapped
> >     along with carveout before triggering _auth_and_reset_.
> >   - IOMMU properties need to be added to firmware devices tree node when Linux
> >     control IOMMU.
> > 
> > ---
> > Mukesh Ojha (14):
> >        dt-bindings: remoteproc: qcom,pas: Add iommus property
> >        firmware: qcom_scm: Remove redundant piece of code
> >        firmware: qcom_scm: Rename peripheral as pas_id
> >        firmware: qcom_scm: Introduce PAS context initialization helper function
> >        remoteproc: pas: Replace metadata context with PAS context structure
> >        soc: qcom: mdtloader: Add PAS context aware qcom_mdt_pas_load() function
> >        soc: qcom: mdtloader: Remove qcom_mdt_pas_init() from exported symbols
> >        firmware: qcom_scm: Add a prep version of auth_and_reset function
> >        firmware: qcom_scm: Simplify qcom_scm_pas_init_image()
> >        firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEE
> >        firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table
> >        remoteproc: pas: Extend parse_fw callback to fetch resources via SMC call
> >        remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by Linux
> >        arm64: dts: qcom: Add EL2 overlay for Lemans
> > 
> >   .../bindings/remoteproc/qcom,pas-common.yaml       |   3 +
> >   arch/arm64/boot/dts/qcom/Makefile                  |  10 +
> >   arch/arm64/boot/dts/qcom/lemans-el2.dtso           |  41 +++
> >   drivers/firmware/qcom/qcom_scm.c                   | 387 ++++++++++++++++++---
> >   drivers/firmware/qcom/qcom_scm.h                   |   1 +
> >   drivers/remoteproc/qcom_q6v5_pas.c                 | 166 +++++++--
> >   drivers/soc/qcom/mdt_loader.c                      |  43 ++-
> >   include/linux/firmware/qcom/qcom_scm.h             |  30 +-
> >   include/linux/soc/qcom/mdt_loader.h                |  22 +-
> >   9 files changed, 593 insertions(+), 110 deletions(-)
> > ---
> > base-commit: 9823120909776bbca58a3c55ef1f27d49283c1f3
> > change-id: 20251104-kvm_rproc_v6-6329e4d594fe
> > 
> > Best regards,
> > --
> > -Mukesh Ojha
> > 
> > 
> 

-- 
-Mukesh Ojha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ