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

Message-ID: <1300f2ff-7aa3-4003-8be7-c87f671d22aa@gmail.com>
Date: Wed, 21 Aug 2024 19:27:33 +0200
From: Konrad Dybcio <konradybcio@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>,
 Melody Olvera <quic_molvera@...cinc.com>,
 Trilok Soni <quic_tsoni@...cinc.com>,
 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 21.08.2024 8:48 AM, Krzysztof Kozlowski wrote:
> On 20/08/2024 21:19, Konrad Dybcio wrote:
>> On 20.08.2024 8:21 PM, Melody Olvera wrote:
>>>
>>>
>>> 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.
>>
>> Well in that case I suppose a new compatible / property (please voice
>> your opinion Krzysztof) is necessary after all.. Thanks for making sure
> 
> You mean the "secure" part? Sure, I don't object that, although
> (repeating as usual) I am not in favor of it in the first place, be
> cause you should use only SoC compatibles.
> 
> The objection here was for dropping specific front compatible, without
> any relevant explanation.

Is EUD-non-secure in use on both Chrome and LA firmwares on 7280?

Konrad