Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez <leonard.crestez@nxp.com>]

On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>> I don't yet buy the security argument. There are many more shared parts
>>> on the SoC, like the clock controller, that would need to be taken away
>>> from the non-secure world if one would want to run an untrusted OS
>>> kernel on a i.MX8M system.
>>>
>>> To properly implement security on any i.MX8M based system the firmware
>>> would need to grow something like a full ARM SCPI implementation, so
>>> all shared critical peripherals are solely under firmware control.
>>
>> It might be possible to rework this to use some form of SCMI-over-SMC
>> instead of vendor-specific SMCCC SIP calls
> 
> Sounds feasible and good if all the custom IDs/calls/..etc are well
> hidden in the firmware(TF-A in this case) behind the existing
> abstraction in Linux kernel.

>> Hiding everything critical for security (especially CCM) behind a SCMI
>> interface would be a large amount of work but introducing SCMI
>> incrementally (starting with imx8mm power) would be useful by itself
>> because it simplifies OS implementation.
> 
> Agreed, but not at the expense of introducing and maintaining *random*
> *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> 
>> Many at NXP have attempted to evaluate SCMI and their conclusion has
>> always been that "many extensions are required".
> 
> I would like to hear the evaluation. Don't assume that you need to
> implement something similar to ARM SCMI reference design. All OSPM like
> Linux kernel cares is conformance to the interface, what/how you
> implement on the other side is left to you.

Brief summary from some attempts at nudging NXP devs towards SCMI:


There is no SCMI-over-SMC support specified? This would make it possible 
to use SCMI as a purely software solution on platforms which did not 
take SCMI into account at hardware design time or which don't have a 
dedicated SCP inside the SOC. This applies to all imx.

Peng has been looking at some out-of-tree arm-smc-mailbox patches so 
it's not just NXP which would like the option of implementing SCMI 
vendor side in ATF. Like this: https://lwn.net/Articles/726861/

Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI 
message in EL2; checking if the guest is allowed to use that resource 
and then either forward to EL3 or return an error.


SCMI clock protocol does not cover muxes? On imx the clk hierarchy is 
very intricate and it relies on many clk core features (including 
notifiers) and occasional assigned-clocks-parents properties to control 
muxes from linux. Moving all that to firmware would be a huge amount of 
effort.

If SCMI included a generic clk mux and allowed keeping the clk hierarchy 
inside linux then the effort required for hiding the CCM would still be 
large, but more approachable. It would not "simplify the rich OS" but it 
would still improve security.


Last point is that SCMI does not cover pinctrl? This is a large chunk of 
firmware functionality on some imx and security control over individual 
pins is desirable.

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel