Am Mittwoch, den 17.04.2019, 12:40 +0000 schrieb Leonard Crestez: > On 4/17/2019 3:13 PM, Lucas Stach wrote: > > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: > > > > From: Jacky Bai > > > > Sent: Wednesday, April 17, 2019 1:27 PM > > > > > > > > The i.MX8M family is a set of NXP product focus on delivering the latest and > > > > greatest video and audio experience combining state-of-the-art media-specific > > > > features with high-performance processing while optimized for lowest power > > > > consumption. > > > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to > > > > this family. > > > > > > > > The GPC module is used to manage the PU power domains' power on/off. For > > > > the whole i.MX8M family, different SoC has differnt power domain design. the > > > > power up sequence has significant difference. > > > > all the power sequence must be guaranteed by SW. Some domains' power up > > > > sequence need to access the SRC module or sub-system specific GPR. > > > > the SRC register & SS's register are not in in the GPC's memory range. > > > > > > > > it makes us hard to use the GPCv2 driver to cover all the different power up > > > > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver > > > > to make it resuable for it. a lot of code need to be added in GPCv2 to support it. > > > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be > > > > self-contained. Accessing the non-driver specific module's register is a bad > > > > practice. Although, the GPC module provided the similar function for PU power > > > > domain, but it is not 100% compatible with GPCv2. > > > > > > > > The most important thing is that the GPC & SRC module is a security critical > > > > resource that security permission must be considered when building the > > > > security system. The GPC module is not only used by PU power domain power > > > > on/off. It is also used by the TF-A PSCI code to do the CPU core power > > > > management. the SRC module control the CPU CORE reset and the CPU reset > > > > vector address. if we give the non-secure world write permission to SRC. > > > > System can be easily induced to malicious code. > > > > > > Considering the security issue, it looks to me a right direction to move GPC > > > power handling into ATF. > > > It also helps build a more generic driver and ease other OS integration > > > needed by customers (e.g. QNX, Win10). > > > > > > Lucas, > > > How do you think of it? > > > > 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 > > +SCMI maintainer > > > 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. > > 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. I'm totally on-board with baby steps if it gets us into the right direction, so what you propose makes sense to me. What I'm not okay with is tying the upstream kernel into an ad-hoc firmware interface in the name of system security, if there is no chance that proper security will ever be able to be achieved with the ad-hoc interface. Having dependencies between the OS kernel and system firmware is a burden on system integrators and I'm only willing to accept that burden if it's clear that there is some real value to it. Regards, Lucas
