| Message ID | 20211209120626.26373-1-srinivas.kandagatla@linaro.org |
|---|---|
| Headers | show |
| Series | misc: fastrpc: Add missing DSP FastRPC features | expand |
On 13/12/2021 15:46, Bjorn Andersson wrote: > On Thu 09 Dec 04:06 PST 2021, Srinivas Kandagatla wrote: > >> From: Jeya R <jeyr@codeaurora.org> >> >> Add property to set DSP domain as non-secure. >> >> ADSP/MDSP/SDSP are by default secured, where as CDSP can be either be >> secured/unsecured. >> non-secured Compute DSP would allow users to load unsigned process >> and run hexagon instructions, but limiting access to secured hardware >> within the DSP. >> >> Based on this flag device nodes for secured and unsecured are created. >> >> Signed-off-by: Jeya R <jeyr@codeaurora.org> >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> >> --- >> >> This patch has dependency this yaml conversion patch: >> https://lore.kernel.org/lkml/20211208101508.24582-1-david@ixit.cz/T/ >> >> Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml >> index f42ab208a7fc..f0df0a3bf69f 100644 >> --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml >> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml >> @@ -29,6 +29,11 @@ properties: >> - sdsp >> - cdsp >> >> + qcom,non-secure-domain: >> + type: boolean >> + description: > >> + Property to specify that dsp domain is non-secure. > > "non-secure" feels vague, how about expressing it as "Specifies that the > domains of this DSP instance may run unsigned programs." TBH I dont mind either of this, but looking at some existing bindings I see similar pattern of properties like.. "st,non-secure-otp" > > Perhaps even go so far to name the property > qcom,allow-unsigned-programs? (Or some other word for "program"?) Do you think adding more details in the description would help? --srini > > Regards, > Bjorn > >> + >> '#address-cells': >> const: 1 >> >> -- >> 2.21.0 >>
On 13/12/2021 13:19, Stephan Gerhold wrote: > On Mon, Dec 13, 2021 at 12:35:40PM +0000, Srinivas Kandagatla wrote: >> On 13/12/2021 10:57, Stephan Gerhold wrote: >>> On Thu, Dec 09, 2021 at 12:06:23PM +0000, Srinivas Kandagatla wrote: >>>> From: Jeya R <jeyr@codeaurora.org> >>>> >>>> Add property to set DSP domain as non-secure. >>>> >>>> ADSP/MDSP/SDSP are by default secured, where as CDSP can be either be >>>> secured/unsecured. >>> >>> Wouldn't it be easier to avoid the negation and add a "qcom,secure-domain" >>> property instead? Given PATCH 8/8 ("arm64: dts: qcom: add non-secure >>> domain property to fastrpc nodes") it looks like you are intentionally >>> breaking DT compatibility here, but this patch does not justify why this >>> is necessary. >> >> By default all ADSP/MDSP/SDSP are secured, so this property is only required >> for something that is not default. Only case that is configurable is the >> CDSP case where in by adding this flag we should be able to load an unsigned >> process to dsp using unsecured node. >> >> Having said that, TBH When we first added the fastrpc patchset we did not >> take care of this security feature properly :-) >> >> From security point of view, its better to keep the default as secured >> rather than unsecured in DT too. >> >> With this DTS patch older dts should continue to work. >> > > Is this a "default" on newer platforms only? Why do the existing > platforms not use the "secure" setup then? Or is this perhaps firmware > version/configuration specific? So I did bit of digging at old msm kernels spoke to Qualcomm on this. This feature was added in Dec 2018 and after. So ADSP/MDSP/SDSP are by secured by default for SoCs SDM845 and after. However when we upstreamed the first fastrpc driver (end of 2018 early 2019) we did not take this new feature into consideration and we now ended up with most recent SoCs accessing the only available non secured device node. This new property serves three purposes 1. supporting the older SoCs (msm8916 msm8996) that did not have this secure node, 2. Allow CDSP configuration of secured/unsecured. 3. keep the new SoCs working (sdm845, sm8150, sm8250, sm8350) with existing upstream driver. (This is purely for not breaking existing applications). We could do the right thing here by making only msm8916 non-secured and let all the new SoCs like sdm845 and later be by default secured on ADSP/MDSP/SDSP and only configure CDSP. > > Basically I'm confused because you say that the "default" is the secured > setup, but DT patch (8/8) suggests that non-secure is the default on > pretty much all currently supported platforms (msm8916, sdm845, sm8150, > sm8250, sm8350). :) I agree there is a bit of confusion, I hope my reply clears this. --srini > > Thanks, > Stephan >