On Mon, Jan 16, 2012 at 2:13 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote: >> This code will be in assembly and that's what I have >> been using. Not having stack shoudn't be a blocker >> and can be work-around in this code. And this API >> has to be anyway called before MMU is enabled. > > What about SMC on OMAP potentially corrupting most of the integer > registers? What if it corrupts an integer register which we depend > upon? You don't have a stack here to save those registers. We'd > need at least one additional register to save the old 'lr' value. > That's right. > What about other secure monitors? Some implementations require you to > give parameters via memory. How do you obtain that memory that early > on in the kernel boot (you haven't parsed anything here.) > > Not only that but you're asking to make the kernel boot a _lot_ more > fragile, when people start stuffing all kinds of utter shite into this > hook - and then we're burdened again with the old 'my kernel won't > boot and it remains silent, well your debug code is utter shite get rid > of it' crap that we used to have in the early 2000s. > > I really don't want to go anywhere near that situation. > Fair point. It will be harder to maintain and won't be consistent. >> Am not sure what you mean because secure API >> as such isn't a problem. If you mean one standard interface >> for all the ARM SOC's then that's something won't be >> easy to handled because it is tied up the security architecture >> which can vary across SoCs. > > The latter. This is exactly the kind of pain I forsaw with this security > shite, and when I heard about it I was utterly dismayed at ARM Ltd for > coming up with such a brain-dead lack of design here. > > You're having to struggle with the results of that by having lots of > SoC specific hooks all around the place to fiddle with this that and the > other. Your need to have something called from the early assembly code > is just yet more of that disease caused by ARM Ltd's lack of forsight > on this matter. > > I have no solution for you on this I managed use some secure macro kind of code but as you said it will be really hard to maintain. So we are stuck with this issue then. Regards Santosh -- 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
