[U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state

[Mj Embd]

Hello Andre,
I need a bit clarification here, if you read the next line after the line
you have quoted. It clearly says that you can use a MCR to change from
Secure to NS in Monitor Mode
"Use an MCR instruction that writes SCR.NS to change from Secure to
Non-secure state. This means ARM recommends that software does not alter SCR.NS
in any mode except Monitor mode. ARM deprecates changing SCR.NS in any
other mode."



On Fri, Sep 20, 2013 at 3:09 AM, Mj Embd <mj.embd at gmail.com> wrote:

>
>
>
> 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
>



-- 
-mj