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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux