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. -- 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
