On Fri, Sep 09, 2011 at 09:15:20AM +0100, Russell King - ARM Linux wrote:

On Fri, Sep 09, 2011 at 03:32:48PM +0800, Shawn Guo wrote:

quoted

quoted

Now to the physical act of enabling the L2 cache.  The L2 cache control
registers are subject to security restrictions when running in non-secure
mode, needing platform specific SMC calls to reprogram the cache.  Generic
code is unable to do this.

I could be very possibly wrong here.  But isn't the core in secure mode
upon reset?  Do we really have to reprogram L2 through SMC calls there?

It probably will be, but the core won't be running the resume function
directly on reset.  (No ARM CPU does this - not even the pre-security
ones.  They've traditionally run the boot loader first.)

Some naive boot ROM may simply jump to the resume entry address saved
in persistent register.

Take a moment to think about this in terms of security of data stored on
the secure side (where there maybe private keys stored.)

The kernel runs in the non-secure side of the partition.  If it were to be
entered on resume in secure mode, it could access those keys.  That would
be a really great security hole, which would make the whole thing pointless.

What would happen is the secure monitor ROM code gets control first, just
like it does at normal boot time on secure devices.  Eventually, the kernel
will gain control but only after the secure monitor has switched to
non-secure mode.

Then the question is that for given bad boot ROM, whether kernel resume
routine should stand up to fill the hole up.

-- 
Regards,
Shawn