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

Message-ID: <8B3AF14A70DEB168+16bb085f-6930-45c2-ab70-83eef50624b5@radxa.com>
Date: Sat, 31 Jan 2026 00:45:14 +0800
From: Junhao Xie <bigfoot@...xa.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, 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/30 22:10, Miquel Raynal wrote:
> Hi,
>
>>> 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.
> If it's a MAC address that you are accessing, direct userspace does not
> sound like a good fit. If I may, NVMEM cells are there exactly for this
> purpose: identifying the content of a subpart of a storage device in a
> storage agnostic way. The NVMEM cells are made available to in-kernel
> drivers (ie. network devices have all the infrastructure to get the MAC
> address from there) and their content is also exposed to userspace
> through sysfs now.

Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP"
partition contains a FAT file system, and the MAC address is stored in
one of these files.

Because the data is stored inside a filesystem rather than at a fixed
offset, it does not fit well with the NVMEM model, which assumes simple
offset-based access.

Accessing this would require the kernel to directly read files from a
filesystem, which is generally not appropriate, so this should probably
not be accessed from kernel.

> Thanks,
> Miquèl

Best regards,
Junhao Xie