[RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[Haozhen Li]

The QSEECOM interface in qcom_scm.c currently only supports interacting
with pre-loaded trusted applications via qcom_scm_qseecom_app_get_id() and
qcom_scm_qseecom_app_send(). It lacks support for loading applications at
runtime, unloading them, and servicing normal-world listener requests.

When an application requires normal-world interaction, the SMC returns
QSEECOM_RESULT_INCOMPLETE. Currently, qcom_scm_qseecom_call() issues a
WARN_ON() and returns 0 on incomplete calls, leaving the application
blocked in TrustZone and rendering subsequent QSEECOM calls unresponsive
(-EBUSY). This behavior is the primary reason the driver currently relies
on a machine allowlist (qcom_scm_qseecom_allowlist).

Design rationale:
Currently, QSEECOM expects apps to be pre-loaded by early bootloaders.
However, runtime loading via APP_START is required for modular devices
and trusted applications (e.g. fingerprint) whose lifecycles are tied to
user-space daemons or loadable drivers. Furthermore, dynamic loading and
unloading frees secure-world memory when the app is idle. We believe
providing qcom_scm_qseecom_app_load() and shutdown() within qcom_scm is
the least intrusive way to expose this firmware capability, but feedback
on whether this belongs here or should eventually hook into a higher-level
tee subsystem is very welcome.

This series implements the missing app-manager and listener commands:

Patch 1 adds qcom_scm_qseecom_app_load() and
qcom_scm_qseecom_app_shutdown() using the APP_START and APP_SHUTDOWN SMC
commands. It supports both split (.mdt) and single signed ELF images, and
enforces a <4 GiB physical address check required by the 32-bit SMC32
arguments.

Patch 2 introduces listener registration and request handling. During an
incomplete call, qcom_scm_qseecom_call() dispatches the request to the
registered listener callback and returns the result via LISTENER_RESPONSE.
An iteration limit prevents indefinite blocking in case of misbehaving
applications. The listener shared buffer is conservatively required to lie
entirely below 4 GiB, mirroring the image constraint of patch 1.

Removing the machine allowlist is deferred to follow-up work once existing
callers have been verified for re-entrancy.

This work builds upon the QSEECOM transport logic developed by Dawid Wrobel
and samcday [1], adapted to modern mainline interfaces (qcom_tzmem,
lockdep, and proper kerneldoc constraints).

In accordance with Documentation/process/generated-content.rst: an AI
assistant was used to port the transport logic onto current mainline APIs
and to draft the kerneldoc and commit messages. The architecture and code
were reviewed and validated on hardware by the author, who assumes full
DCO responsibility.

Build-tested on arm64 with defconfig and CONFIG_QCOM_QSEECOM=y (W=1 clean,
checkpatch --strict clean).

The transport logic this series ports has been exercised on hardware
before: on SDM670 through the work it derives from [1], and on sc8280xp
(huawei,gaokun3) through the equivalent out-of-tree patch. This exact
series has been boot-tested on sc8280xp (huawei,gaokun3) with an
out-of-tree client of the fingerprint trusted application: trustlet
loading and shutdown verified across multiple start/shutdown cycles
with consecutive loads succeeding (confirming that APP_SHUTDOWN releases
the secure-world memory and name), sensor initialization and image
capture stable across repeated enroll and verify transactions, and no
dmesg regressions compared to the out-of-tree baseline.

[1] https://github.com/samcday/linux
    branch codex/sargo-fingerprint-kernel11-baseline

Signed-off-by: Haozhen Li <dezige131@foxmail.com>

Haozhen Li (2):
  firmware: qcom: scm: Add QSEECOM app loading and shutdown
  firmware: qcom: scm: Handle QSEECOM listener callbacks

 drivers/firmware/qcom/qcom_scm.c       | 394 ++++++++++++++++++++++++-
 include/linux/firmware/qcom/qcom_scm.h |  62 ++++
 2 files changed, 444 insertions(+), 12 deletions(-)


base-commit: cbbddb6b08cc9900a87cccaa9b22bbe06aa4f50a
-- 
2.43.0

Re: [RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[Dawid Wrobel]

On 1.11.2026 17:01, Haozhen Li wrote:

> This work builds upon the QSEECOM transport logic developed by Dawid Wrobel
> and samcday [1] 

I would have preferred you filed your updates to my code as a PR to my
repo at https://github.com/wrobelda/linux/tree/qcom-qseecom-tee/

While my work is indeed AI-assisted, I made a substantial effort to
design it properly and review and fix the code by hand where it
mattered, yet I still don't consider it admissible here for mainline
inclusion yet. Notably, there's also a substantial amount of
documentation I have written by hand specifically to submit it along the
qseecom code. I was looking to file an RFC here this month myself for
all this.

The code in this RFC is, at rough estimate, 80-90% mine. While you did
retain Copyright notice in the source file, I believe the guidelines say
you should have tagged the Co-developed-by: together with a
Signed-off-by:, which you should have asked for from me.

You also mention Sam Day, who filed a PR against my TEE driver, but he
wasn't CC-ed, so I am doing that.

> adapted to modern mainline interfaces (qcom_tzmem, lockdep, and proper
kerneldoc constraints).

What exactly did you adapt, because as far as I am concerned, my code
*already* does exactly all that?

Lastly, as Konrad pointed out, these interfaces need an in-kernel
consumer. My work provides one:

- a QSEECOM TEE driver, which uses the interfaces in this RFC:
  https://github.com/wrobelda/linux/tree/qcom-qseecom-tee
- a Goodix SPI fingerprint sensor driver:
  https://github.com/wrobelda/linux/tree/goodix-fp-spi
- a user-space stack (two supplicant daemons and an fprintd patch),
  described at https://github.com/wrobelda/goodix-fp-spi-linux

As mentioned, I will appreciate your patches as PRs to my repo,
as the FOSS etiquette dictates and let me file a proper RFC once
I decide it's good to go.

-- 
With Kind Regards,
Dawid Wrobel

Re: [RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[Haozhen Li]

Hi Dawid,

I owe you a sincere apology. I should have reached out and coordinated
with you before sending anything based on your work, asked for your
Co-developed-by: and Signed-off-by: tags, and verified the origin
properly. I am truly sorry for stepping on your toes and mishandling
the attribution.

For context, and not as an excuse: my sole goal with this series was
to bring up the fingerprint sensor on my device (huawei,gaokun3 /
sc8280xp), and the codebase I started from was Sam's snapshot [1].
During that process I made the mistake of relying on an AI assistant
for the porting and background research, and failed to verify that it
had traced the upstream lineage back to your active qcom-qseecom-tee
branch. Consequently, my cover letter's claim of "adapted to modern
mainline interfaces" was written relative to Sam's older snapshot and,
as you rightfully pointed out, is simply incorrect regarding your
repository. The core architecture and design, such as the listener
loop and its iteration bounds, are entirely your work, and the
attribution in my RFC fell far short of proper DCO standards.

I am withdrawing this series immediately. Your tee: qseecom driver,
with the Goodix sensor driver on top, is exactly the complete in-tree
consumer Konrad asked for, and your upcoming RFC is unquestionably the
right vehicle to bring this infrastructure to mainline.

I would be honored to contribute back to your tree, entirely at your
discretion:

 - A PR adding defensive checks for image and listener shared buffers
   above the 4 GiB physical mark, using the overflow-safe comparison
   Konrad suggested [2]. For what it is worth, I probed this on
   sc8280xp by OR-ing bit 32 into an otherwise valid image address:
   the firmware rejected the APP_START call with an explicit error
   rather than silently truncating the address, so this is strictly
   defensive hardening, not a fix for a universal firmware defect.

 - Testing on different silicon: I have exercised this transport on
   sc8280xp with a FocalTech fingerprint TA through repeated
   load/shutdown cycles and enroll/verify transactions, and would
   gladly run your tree on this hardware before you file your RFC and
   provide a Tested-by.

On the userspace side, I also maintain an independent D-Bus daemon
implementing net.reactivated.Fprint directly, without patching fprintd
or libfprint. Happy to compare notes if that is ever a useful data
point for the wider fingerprint ecosystem.

Thank you for your candid feedback, for CC-ing Sam, and above all for
the groundwork that made my device bring-up possible in the first
place.

Best regards,
Haozhen Li

[1] https://github.com/samcday/linux
    branch codex/sargo-fingerprint-kernel11-baseline
[2] Konrad's reply on the patch 1 thread

Re: [RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[Dawid Wrobel]

On 2.11.2026 17:27, Haozhen Li wrote:
> Hi Dawid,
> 
> I owe you a sincere apology.

Hi Haozhen. None are needed, but appreciated. I may have come on too
strong but still expected this to turn out to be a mere misunderstanding.


> I would be honored to contribute back to your tree, entirely at your
> discretion:
> 
>  - A PR adding defensive checks for image and listener shared buffers
>    above the 4 GiB physical mark, using the overflow-safe comparison
>    Konrad suggested [2]. For what it is worth, I probed this on
>    sc8280xp by OR-ing bit 32 into an otherwise valid image address:
>    the firmware rejected the APP_START call with an explicit error
>    rather than silently truncating the address, so this is strictly
>    defensive hardening, not a fix for a universal firmware defect.

Absolutely. I did apply a hopefully more idiomatic approach, which
considers the QSEE version, as suggested by Konrad, and sets a
dma_set_coherent_mask(scm->dev, DMA_BIT_MASK(32)) on QSEE older than
TZ.BF.4.0, following what downstream Android qseecom driver does.

>  - Testing on different silicon: I have exercised this transport on
>    sc8280xp with a FocalTech fingerprint TA through repeated
>    load/shutdown cycles and enroll/verify transactions, and would
>    gladly run your tree on this hardware before you file your RFC and
>    provide a Tested-by.

Absolutely and testing on more silicon is what I hoped for before filing
an RFC here, so this is still very much welcome and appreciated.

> On the userspace side, I also maintain an independent D-Bus daemon
> implementing net.reactivated.Fprint directly, without patching fprintd
> or libfprint. Happy to compare notes if that is ever a useful data
> point for the wider fingerprint ecosystem.

Absolutely, let's take it of the ML to reduce the noise and switch to my
repo.

> Thank you for your candid feedback, for CC-ing Sam, and above all for
> the groundwork that made my device bring-up possible in the first
> place.

Appreciate it.

-- 
With Kind Regards,
Dawid Wrobel