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: <CAA8EJprDTz7b4rNtR4e9A-=j9_z-aJGBg3+g5is8Bmy=cgTM1Q@mail.gmail.com>
Date: Wed, 13 Nov 2024 13:50:52 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Ekansh Gupta <quic_ekangupt@...cinc.com>
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 Wed, 13 Nov 2024 at 08:18, Ekansh Gupta <quic_ekangupt@...cinc.com> wrote:
>
>
>
> 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?

Thank you for the explanation, and thanks for the description of the
expected behaviour, but the question is different.
Currently (with the property being present in DT) the driver creates a
non-secure fastrpc device for the ADSP.
Can it actually be used? Note: no mentioning of a particular userspace
implementation or the (un)expected usage.
If it could not and an attempt to use it resulted in some kind of an
error, then the patch is a fix and it should be decribed accordingly.
If it could be used and now you are removing this possibility, then it
is a regression. Again, this must be clearly documented, but generally
this is not allowed.

>
> --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
> >>
>


-- 
With best wishes
Dmitry