Re: [RFC] arm: Handle starting up in secure mode

[Christopher Covington]

On 09/19/2014 09:30 AM, Catalin Marinas wrote:
> On Fri, Sep 19, 2014 at 02:22:10PM +0100, Christopher Covington wrote:
>> On 09/19/2014 01:56 AM, Peter Maydell wrote:
>>> On 17 September 2014 06:25, Christopher Covington <cov@xxxxxxxxxxxxxx> wrote:
>>>> On 09/16/2014 05:24 PM, Christopher Covington wrote:
>>>>> On 09/16/2014 05:09 PM, Christopher Covington wrote:
>>>>>> ARM Linux currently has the most features available to it in hypervisor
>>>>>> (HYP) mode, so switch to it when possible. This can also ensure proper
>>>>>> reset of newer registers such as CNTVOFF.
>>>>>>
>>>>>> The permissions on the Non-Secure Access Control Register (NSACR) are
>>>>>> used to probe what the security setting currently is when in supervisor
>>>>>> (SVC) mode.
>>>>>
>>>>> Sorry, this doesn't work yet. I was misinterpreting my test results. For what
>>>>> it's worth, my testing and development methodology is to run it after hacked
>>>>> up versions of the semihosting bootwrapper on the simulator that corresponds
>>>>> to rtsm_ve-aemv8a.dtb (AEM VE FVP these days?) and examine the instruction traces.
>>>>
>>>> Looks like the real problem was that I was hacking up the bootwrapper
>>>> incorrectly--my start-in-secure-mode bootwrapper variant wasn't setting up the
>>>> GIC for non-secure access. With that changed, I've tested the following
>>>> variations using the Image file in a single core configuration.
>>>>
>>>> Start in non-secure SVC with non-secure access to GIC configured.
>>>>
>>>> Start in secure SVC with non-secure access to GIC configured.
>>>>
>>>> Start in secure SVC with non-secure access to GIC configured and hypervisor
>>>> support disabled in the model (-C cluster.has_el2=0). This required setting
>>>> the VBAR again in non-secure SVC but with that fix it seems to work. I'll
>>>> include this change in v2.
>>>
>>> If you're relying on the boot loader to set up the GIC to support
>>> non-secure access anyway, why not just have it boot the kernel in Hyp
>>> like the boot protocol document recommends? (The same thing as the GIC
>>> is going to apply for any other hardware that needs configuration to
>>> allow NS access; if we need the firmware to deal with this we might as
>>> well just have it boot us in the right mode too.)
>>
>> I'd like to get rid of as much of the bootwrapper as possible (having gotten
>> spoiled by using QEMU's built-in bootloader). I'm just taking it one step at a
>> time. Handling GIC initialization in the kernel is probably the next step.
> 
> The problem is that the kernel doesn't know about GIC until much later.
> So I don't see an easy workaround, other than relying on the boot-loader
> to do the right thing (and then we go to the point Peter made about
> changing it to start Linux in Hyp mode directly).

My initial thought was to have the later-running GIC driver capable of running
some initialization code in monitor mode. However in reading through the ID
registers, keying off of PFR1.GIC might allow for early initialization on
newer systems.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/