From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family Date: Wed, 17 Apr 2019 14:33:05 +0100 Message-ID: <68aaace3-f66e-b4b8-30a0-57b8b66a7524@arm.com> References: <20190417053211.2195-1-ping.bai@nxp.com> <1555503195.2317.19.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Leonard Crestez , Lucas Stach , Jacky Bai , Peng Fan Cc: Aisheng Dong , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "festevam@gmail.com" , "s.hauer@pengutronix.de" , =?UTF-8?Q?Cl=c3=a9ment_Faure?= , "robh+dt@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Sudeep Holla , Silvano Di Ninno , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org On 17/04/2019 13:40, Leonard Crestez wrote: > On 4/17/2019 3:13 PM, Lucas Stach 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. > +SCMI maintainer > Thanks for including. >> I agree that it might make sense to move some parts into the firmware >> and have much simpler OS level drivers, but I don't agree on the >> implementation direction taken here. Growing custom PSCI extension >> interfaces will only get us so far, without solving the system security >> issue in a holistic way. It is my strong believe that only a complete >> rearchitecture of the OS support on top of a ARM SCPI firmware >> interface can solve this properly. +1 again, just to re-iterate the emphasis on the above and the degree to which I align with it. > 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. -- Regards, Sudeep