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
