On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara <andre.przyw...@linaro.org>wrote:
> 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 > 1. > ..." > > > 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.d...@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 >>> >>> >> >> > -- -mj
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
