linux-kernel - Re: [PATCH v2] usb: misc: qcom_eud: Access EUD_MODE

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: <19507b60-ef03-4fac-96dc-f8700f74c0e1@oss.qualcomm.com>
Date: Sat, 28 Jun 2025 16:00:51 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Komal Bajaj <komal.bajaj@....qualcomm.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Souradeep Chowdhury <quic_schowdhu@...cinc.com>
Subject: Re: [PATCH v2] usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through
 secure calls

On 6/28/25 7:44 AM, Dmitry Baryshkov wrote:
> On Fri, Jun 27, 2025 at 06:21:31PM +0530, Komal Bajaj wrote:
>> EUD_MODE_MANAGER2 register is mapped to a memory region that is marked
>> as read-only for HLOS, enforcing access restrictions that prohibit
>> direct memory-mapped writes via writel().
>>
>> Attempts to write to this region from HLOS can result in silent failures
>> or memory access violations, particularly when toggling EUD (Embedded
>> USB Debugger) state. To ensure secure register access, modify the driver
>> to use qcom_scm_io_writel(), which routes the write operation to Qualcomm
>> Secure Channel Monitor (SCM). SCM has the necessary permissions to access
>> protected memory regions, enabling reliable control over EUD state.
>>
>> SC7280, the only user of EUD is also affected, indicating that this could
>> never have worked on a properly fused device.
> 
> Most likely SC7280 Chrome platforms were fused differently or used a
> different configuration of the TZ.

They were not fused for production, as I understand

> The question is whether there can be other platforms (e.g. SC7180 Chrome
> or SDM845 Cheeza prototypes) which should use direct register access
> instead of going through the SCM.

TF-A currently needs an update to the SCM MMIO R/W address whitelist,
but in any case, a write from !TZ is not going to be accepted by the
hardware

Konrad