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: <86F97239DB3D962C+98826904-6649-4c19-815d-73003c046c14@radxa.com>
Date: Fri, 30 Jan 2026 21:39:48 +0800
From: Junhao Xie <bigfoot@...xa.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Konrad Dybcio <konradybcio@...nel.org>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mtd@...ts.infradead.org, Xilin Wu <sophon@...xa.com>,
 Junhao Xie <bigfoot@...xa.com>
Subject: Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

On 2026/1/29 4:42, Bjorn Andersson wrote:
> On Mon, Jan 26, 2026 at 07:44:50PM +0800, 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.
>>
> Sorry, I missed your reply to me on v1.
>
>
> You replied that this allow your users to update "BIOS" firmware
> directly from Linux, which I can see being more convenient than relying
> on UEFI update capsules, in particular in a development environment.
>
> The concern I have with this is that I don't think an end-user of such
> system, has a way to recover from breaking the content on their SPI-NOR.
>
> As such, exposing such a convenient interface for the end-user to brick
> their devices is probably not a good idea.
>
> I think we should somehow lock the interface down to be read-only by
> default, and perhaps have some mechanism to unlock the write mode (like
> a module parameter expecting the sentence "YES, I DO HAVE THE FIREHOSE
> PROGRAMMER FOR THIS BOARD").
>
>
> I don't believe you answered my question regarding how to access this
> interface from the kernel. On many of these devices we can find the MAC
> addresses of the system in the "DPP" partition. Do you have any ideas
> about how we could access this from within the kernel?
>
> Regards,
> Bjorn

I agree with your point. I will add a module param in v3 for default
read-only mode. e.g.: /sys/module/qcom_scm_storage/parameters/allow_write

For something like the "DPP" partition, I think it's better to access it
from userspace than from kernel.

Best regards,
Junhao Xie