linux-kernel - Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

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: <81ec34a6-8627-4a59-8fc7-87eee4625b2d@quicinc.com>
Date: Tue, 20 Aug 2024 11:21:04 -0700
From: Melody Olvera <quic_molvera@...cinc.com>
To: Trilok Soni <quic_tsoni@...cinc.com>,
        Konrad Dybcio
	<konradybcio@...il.com>,
        Konrad Dybcio <konradybcio@...nel.org>,
        "Krzysztof
 Kozlowski" <krzk@...nel.org>,
        Souradeep Chowdhury
	<quic_schowdhu@...cinc.com>,
        Bjorn Andersson <andersson@...nel.org>, Rob
 Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor
 Dooley <conor+dt@...nel.org>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        "Satya Durga Srinivasu Prabhala"
	<quic_satyap@...cinc.com>,
        Elson Serrao <quic_eserrao@...cinc.com>
CC: <cros-qcom-dts-watchers@...omium.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible
 strings for eud



On 8/14/2024 3:09 PM, Trilok Soni wrote:
> On 8/14/2024 1:25 PM, Konrad Dybcio wrote:
>>> Unfortunately, no. We considered several options, but none guarantee that we will avoid
>>> a crash if we try non-securely. The secure call also won't give a specific error if it fails either
>>> (for security reasons) so we can't know if a secure access failed because it's supposed to be
>>> accessed non-securely or for another reason; hence this approach. If there's
>>> another way to achieve this functionality that might be better, I'm all ears.
>> Can we read some fuse values and decide based on that?
> In most of the cases, these fuse values are not allowed to be read
> from the Linux, so that will be another problem. Melody can check
> if there is any fuse values around here and possible to read them
> through Linux.
>

I double-checked, but there really isn't any kind of fuse or anything we 
can read to determine
how we need to access these registers. I remembered checking before 
authoring these patches,
but I wanted to just make sure before responding here.

Thanks,
Melody