> From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > Sent: Monday, May 18, 2009 4:11 PM > On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote: > > The code flow is: > > - Wakeup event > > - ARM reboots and uses SOC mask ROM context restore helper > > - Mask ROM code jump to restore pointers with MMU OFF. > > - Restore code resets ARM CortexA8 state > > -*- Trustzone SMI calls are made to restore some secure state > > - Jump back from SRAM to C code > > > > The dangling question to me is if any of the cpu state is needed by > > the trustzone monitor code as a precondition. The doc's I have led > > me to believe its ok, but I've not verified this. > > There shouldn't be - it would be _really_ silly if the trustzone monitor > had pre-requisits for the exception mode registers. There's no way that > Linux's use of the exception mode registers is anywhere near the same as > other OSes, and Linux's use of the exception mode registers has changed > over time anyway. We make no promise that we'll keep the way we're using > these registers today either. > > So there are no external guarantees about what useful state the kernel > puts into these registers. Having external code rely on some state > there would itself be broken. > > There's also the problem that if there was a dependency on the insecure > exception mode registers from within the trusted environment, that'd > surely be a rather big security problem in itself. Yes those are reasonable comments. In OMAP2 time security required nasty hacks to Linux vectors code (and other OSes). For OMAP3 the security API does take parameters to say if local OS interrupts are allowed or not. In the case they are there the vector base in monitor is used. Some stacking does occur to allow return. So yes as long as local IRQs are off it should be ok. Changes still need validation. Security does something to SOC resources like DMA which have caused confusion. For instance you call the API and specify a DMA channel. This is ok. But you will find some status left in channel which needs clean up before a successful sleep can happen. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
