On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara andre.przywara@linaro.orgwrote:
On 09/19/2013 10:38 PM, Mj Embd wrote:
Hello Christoffer,
I agree with both of you points.
What I found different in 2 approaches is that in your approach S->Monitor->NS->Hyp using svc and hvc
While the other approach is setting the M bits directly in cpsr
Xen uses the following
cpsid aif, #0x16 /* Enter Monitor Mode*/ .... ... mrs r0, cpsr /* Copy the CPSR */ add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ msr spsr_cxsf, r0 /* into the SPSR */ movs pc, r3 /* Exception-return into Hyp mode */
The second one is a bit simpler as it does not involve fault handlers.
The ARM ARM recommends _not_ to do this: Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: Security states/Changing from Secure to Non-secure state:
"To avoid security holes, software must not: -- Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor mode to some other mode while SCR.NS is
..."
Good one, As per this statement from Secure Monitor to Hyp Mode, HVC
should be used. But Secure Supervisor to Secure Monitor does not set NS=1 so first part cpsid aif, #0x16 is valid ? Or there is some other statement in the manual which I am not aware of ?
I was just suggesting that the best approach to be used ...
Looks like this is what we do ;-)
Regards, Andre.
On 9/20/13, Christoffer Dall christoffer.dall@linaro.org wrote:
On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote:
two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set)
For KVM the boot procedure for Hyp mode is quite clearly defined: the kernel must be booted in Hyp mode.
I was under the impression that Xen wanted to use the same paradigm and rely on bootloaders to switch to Hyp mode and thereby get rid of the code in Xen.
(b) There are 2 methods of switching from Secure to Hyp mode
one you have proposed another implemented in xen. I was suggesting take the best approach
Can you please be more specific? Not everyone here knows the Xen low-level mode switch details by heart. As far as I know, there is only one architecturally defined proper mode to switch from secure mode to non-secure mode, and the state that needs to be configured for Hyp-mode and NS-mode is well defined. Obviously two implementation can do things differently (different order, different programminge environment, etc.) but that doesn't mean one is better than the other.
I think it would be more productive if you can simply look at this code and if you think some things are done more efficiently in Xen, please comment on that, which would be very helpful. I'm afraid there's no magic way to apply a block of Xen code into U-Boot wihtout manual adjustment anyway, or the other way around for that matter.
-Christoffer