Hi Russell, > > > > > > > > > > > > On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote: > > > > > > > To boot Linux in Non-secure mode with l2x0, the l2x0 > > > > > > > controller is enabled in secure mode and ways locked to make > > > > > > > it seems L2 cache disabled during linux boot process. So > > > > > > > during l2x0 initialization, need to unlock the ways to make > > > > > > > l2x0 could > > cache data/inst. > > > > > > > > > > > > Why was this chosen instead of doing what everyone else does? > > > > > > > > > > I am not aware of how other platform handles the l2x0 unlock in > > > > > non secure mode. Could you please share with me what others choose? > > > > > > > > That's not what I was asking. > > > > > > > > Everyone else provides a way for the l2x0 controller to be enabled > > > > and disabled from non-secure mode. > > > > > > Thanks for the information. I see that some platforms implements > > l2c_write_sec. > > > > > > > > > > > Why have you decided to enable the l2x0 controller and leave it > > > > enabled, and then lock down all the cache ways - which means you > > > > need the kernel to do something entirely different for your platform. > > > > > > Currently we are running OP-TEE on i.MX6/7 with Linux in non-secure > > > mode. See In > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > it > > > hub.com%2FOP- > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern > > > > > el%2Fgeneric_entry_a32.S%23L428&data=02%7C01%7Cpeng.fan%40nxp.com% > > 7C32 > > > > > > e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > > C0% > > > > > > 7C0%7C636473747645673295&sdata=ZGaxxhs8mPNcqk5l2aSiStkPRFNxLzFFj45w > > kj% > > > 2Ff%2Fu4%3D&reserved=0 > > > Pl310 is enabled. And In > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > it > > > hub.com%2FOP- > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern > > > > > el%2Fgeneric_entry_a32.S%23L461&data=02%7C01%7Cpeng.fan%40nxp.com% > > 7C32 > > > > > > e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > > C0% > > > > > > 7C0%7C636473747645673295&sdata=rO1LG3639lfclvtgzZRTTPcSAGDQNG0Clqb > > D1wC > > > 4wGk%3D&reserved=0 > > > pl310 locked before returning back to Linux. > > > > > > I see ti platform not enabled pl310 in OP-TEE, leaving Linux to > > > enable it. platform-sam/stm/ zynq7k/imx Have pl310 enabled in OP-TEE. > > > > > > I could switch to use l2c_write_sec dedicated for i.MX. But I think > > > this patch is > > also a valid point. > > > What do you suggest? > > > > What I'm concerned about is that there's a valid scenario where the L2 > > cache would be enabled and left enabled by the secure mode code - that > > is if the secure mode wishes to take advantage of the L2 cache, and > > has locked down some ways for its own use. > > > > In this scenario, the secure world would have set the L2 cache up to > > prevent the non-secure side unlocking those ways. This would mean > > that the NS_LOCKDOWN bit in the auxiliary control register would be > > clear. The PL310 TRM has this to say: > > > > "On reset the Non-Secure Lockdown Enable bit is set to 0 and Lockdown > > Registers are not permitted to be modified by non-secure accesses. In > > that configuration, if a non-secure access tries to write to those > > registers, the write response returns a DECERR response." > > > > which means that if we blindly try and unlock the ways, we will end up > > triggering an exception, and that will crash the kernel.
Just have a follow up question. If implementing l2c_write_sec, the kernel image could not only running in non-secure world. If we want the image to support running in secure and non-secure world, do you have any suggestions about the l2c things? Thanks, Peng. > > Currently, we set auxiliary control register to let NS could unlock. BIT26 > set to 1. > But you bring a valid point is if TEE would like to lock down some ways for > its > own use, l2c_write_sec should be used, to avoid Linux to directly unlock. > > > > > Given that the kernel does _not_ handle this scenario today, I fail to > > see why OP-TEE would decide that, on ARM by default, it will enable > > the L2 cache and lock all ways. > > > > As you have already found, at least OMAP has decided to do things > > sensibly. I fail to see why everyone else can't also decide to do the > > sensible > thing. > > Most platforms just set BIT26 to allow non-secure unlock ways without > considering reserving ways dedicated to TEE. > > i.MX also has BIT26 set, so if l2c_init is not a good place, do you think > moving > unlock to imx_init_l2cache is ok? But this means "enabling(unlock)" L2C > earlier > which is before l2c_init > > > > > Please talk to the OP-TEE folk to see whether the OP-TEE behaviour can > > be changed first. > > +OP-TEE maintainers Etienne, Jens > Do you have comments on this? > > Thanks, > Peng. > > > > > -- > > RMK's Patch system: > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > > > armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpeng.fan%4 > > > 0nxp.com%7C32e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92c > > > d99c5c301635%7C0%7C0%7C636473747645673295&sdata=4i8a6dYNkHlMXiYQZ > > N9Ej4b68q%2FZfMCZvIUfJtFy0Jc%3D&reserved=0 > > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down > > 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
