linux-kernel - Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

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: <42c1c820-f235-4d7b-af58-c0b9a4d331cb@oss.qualcomm.com>
Date: Thu, 29 Jan 2026 15:17:35 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Junhao Xie <bigfoot@...xa.com>,
        Trilok Soni <trilokkumar.soni@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mtd@...ts.infradead.org, Xilin Wu <sophon@...xa.com>
Subject: Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

On 1/29/26 1:47 PM, Junhao Xie wrote:
> On 2026/1/29 5:43, Trilok Soni wrote:
> 
>> On 1/26/2026 3:44 AM, Junhao Xie wrote:
>>> This patch series adds support for accessing storage devices managed by
>>> Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by
>>> introducing a new MTD driver.
>>>
>>> On some Qualcomm platforms, firmware or BIOS-related storage (typically
>>> SPI NOR flash) is not directly accessible from the non-secure world.
>>> All read, write, and erase operations must be performed through SCM
>>> interfaces provided by the secure firmware. As a result, existing MTD
>>> SPI NOR drivers cannot be used directly on these systems.
>>>
>>> This series introduces a new MTD device driver that exposes such
>>> firmware-managed storage as a standard MTD device in the Linux kernel.
>>> The driver is built on top of the existing Qualcomm SCM infrastructure
>>> and integrates with the MTD subsystem to provide a uniform interface to
>>> userspace.
>>>
>>> This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm
>>> QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device.
>>>
>>> Note that this platform previously used the standard Qualcomm Linux
>>> firmware, which allowed direct access to the QSPI controller without
>>> needing this driver. However, we plan to migrate to a Windows-compatible
>>> firmware which is more feature-complete but restricts direct access.
>>> Device tree changes for this transition will be sent separately.
>>>
>>> If kernel boots with EL2, access to the SCM storage will be denied. This
>>> needs more investigation.
>> So you plan to enable this driver only w/ the Gunyah based configuration
>> and disable for the KVM one through the devicetree overlay ? I just
>> don't want to break the KVM boot flow on other platforms supporting
>> qcs6490.
> 
> On systems booted with EL2/KVM, the SCM storage GET_INFO call currently
> returns -EINVAL. If a platform does not support SPI-NOR or SCM storage,
> __qcom_scm_is_call_available() will cause the initialization to bail out early.
> 
> There is no DT-based enable/disable mechanism, and this should not affect
> KVM boot flow on other platforms.
> 
> Other QCS6490 LE platforms do not support SCM storage, as the LE firmware
> does not support SPI-NOR boot. Radxa Dragon Q6A uses WP firmware and boots
> from SPI-NOR.
> 
> The root cause of SCM storage being unavailable under EL2/KVM is still under
> investigation.
> 
> [    0.770124] qcom_scm: convention: smc arm 64
> [    0.775005] qcom_scm firmware:scm: qseecom: found qseecom with version 0x1402000
> [    0.782990] qcom_scm firmware:scm: scm storage get info failed: -22
> [    0.999095] qcom_qseecom qcom_qseecom: setting up client for qcom.tz.uefisecapp

I think you need to create a shmbridge when running without gunyah, see
e.g.

4a7d6a78fbc6 ("firmware: qcom_scm: Add a prep version of auth_and_reset function")

where the memory is bridged right before the call. Without knowing any
better I would guesstimate you may need to qcom_tzalloc (which does that
under the hood) the 'struct qcom_scm_storage_info info' which you pass
to that func in qcom_scm_storage_init()

Konrad