linux-kernel - Re: [PATCH v1] arm64: dts: qcom: sc7280: Make ADSP a secure fastrpc domain

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: <c1f0e56b-b489-4370-99e3-0973641410b8@quicinc.com>
Date: Wed, 13 Nov 2024 11:47:47 +0530
From: Ekansh Gupta <quic_ekangupt@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: <andersson@...nel.org>, <konradybcio@...nel.org>, <robh@...nel.org>,
        <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
        <cros-qcom-dts-watchers@...omium.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <srinivas.kandagatla@...aro.org>, <quic_bkumar@...cinc.com>,
        <quic_chennak@...cinc.com>
Subject: Re: [PATCH v1] arm64: dts: qcom: sc7280: Make ADSP a secure fastrpc
 domain



On 11/13/2024 11:13 AM, Dmitry Baryshkov wrote:
> On Wed, Nov 13, 2024 at 10:30:42AM +0530, Ekansh Gupta wrote:
>> FastRPC framework treats ADSP as a secure domain on sc7280 SoC
>> which means that only secure fastrpc device node should be
>> created for ADSP remoteproc. Remove the non-secure-domain
>> property from ADSP fastrpc node.
> If this prevents the non-secure devices from being created, isn't that a
> regression from the userspace point of view?
The actual intention of having secure and non-secure domains is to utilize signed(high privilege)
and unsigned(low privilege) DSP processes properly.

Non-secure device node is intended to be used by untrusted/generic applications which needs to
offload tasks to DSP as unsignedPD. Only unsigned PD is expected to be allowed if the process is
using non-secure node.

Secure device is intended to be used by trusted processes like daemons or any application
which needs to offload as signed PD to DSP.

The ideal expectation from userspace is to first try to open secure device node and fall back to
non-secure node if the secure node is not accessible or absent.

I understand your concerns, can you please suggest how this can be improved/corrected?

--ekansh
>> Signed-off-by: Ekansh Gupta <quic_ekangupt@...cinc.com>
>> ---
>>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 3d8410683402..c633926c0f33 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -3852,7 +3852,6 @@ fastrpc {
>>  					compatible = "qcom,fastrpc";
>>  					qcom,glink-channels = "fastrpcglink-apps-dsp";
>>  					label = "adsp";
>> -					qcom,non-secure-domain;
>>  					#address-cells = <1>;
>>  					#size-cells = <0>;
>>  
>> -- 
>> 2.34.1
>>