[U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Mj Embd
mj.embd at gmail.com
Thu Sep 19 23:39:56 CEST 2013
On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara
<andre.przywara at 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.dall at 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
More information about the U-Boot
mailing list