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

[Adam Ford <aford173@gmail.com>]

On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > 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

I was just curious to know if there is any progress being made on
this.  The i.mx8mm-evk is missing functionality upstream and I think
the power domain support would help enable some of these features.

thanks

adam
> > >
> > > 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:
> >
>
> Thanks for providing the evaluation details.
>
> >
> > 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.
> >
>
> While I admit, the section of SCMI specification that touches transport
> is quite lean, I would view it as done intentionally as the specification
> is mainly concentrated on it's subject matter which is protocol and not
> the transport itself. So did the evaluation attempted to consider/try
> SMC as transport retaining protocol as is ?
>
> I can't see any issues with that and hence I am asking it loud here.
>
> > 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/
> >
>
> OK, any inputs from that study ?
>
> > 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.
> >
>
> Why are you mixing virtualisation and EL2 here ? Yes we need them but
> it should be optional and if a platform doesn't need it, it should be
> possible to skip it.
>
> >
> > 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.
> >
>
> Yes it may be huge amount of work. But is it completely safe as claimed ?
> Giving access to mux controls in OSPM is no so safe/secure in the modern
> world. So you either make it safe with that extra huge effort needed or
> just keep everything in OSPM. But IMO anything in between is not worth it.
>
> > 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.
> >
>
> Why do you need to keep the clk hierarchy in Linux ?
>
> >
> > 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.
> >
>
> Yes but is that something available at runtime ? Can't that be one-off
> firmware setting. Will Linux need to configure it differently on each boot ?
> Just trying to understand. You say security control here and is it really
> safe to give OS access to control those ?
>
> In short, if you had a full blown protocol like few other platforms, the
> push back would have been minimal. Instead, i.MX chose to implement a
> solution which doesn't have a design thought before and custom SMC APIs
> added on fly whenever a new request is raised by OSPM to control things
> that it thinks it should. I am sure, the very next platform will have it's
> own set of requirements and custom SMC APIs/interface and no one has even
> bothered about long term maintenance of these.
>
> So assuming that trend, I would NACK this as it stands.
>
> --
> Regards,
> Sudeep
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel