[U-Boot] [PATCH v4 2/9] efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3

[york sun]

On 06/21/2016 10:55 AM, Alexander Graf wrote:
>
>
>> Am 21.06.2016 um 19:12 schrieb york sun <york.sun at nxp.com>:
>>
>>> On 06/20/2016 04:07 PM, Alexander Graf wrote:
>>> Some boards decided not to run ATF or other secure firmware in EL3, so
>>> they instead run U-Boot there. The uEFI spec doesn't know what EL3 is
>>> though - it only knows about EL2 and EL1. So if we see that we're running
>>> in EL3, let's get into EL2 to make payloads happy.
>>>
>>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>> ---
>>>   arch/arm/include/asm/armv8/mmu.h | 19 ++++++++++++-------
>>>   cmd/bootefi.c                    | 11 +++++++++++
>>>   2 files changed, 23 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
>>> index 0d08ed3..876a2b2 100644
>>> --- a/arch/arm/include/asm/armv8/mmu.h
>>> +++ b/arch/arm/include/asm/armv8/mmu.h
>>> @@ -116,19 +116,24 @@
>>>   static inline void set_ttbr_tcr_mair(int el, u64 table, u64 tcr, u64 attr)
>>>   {
>>>       asm volatile("dsb sy");
>>> -    if (el == 1) {
>>> +    switch (el) {
>>> +    case 1:
>>>           asm volatile("msr ttbr0_el1, %0" : : "r" (table) : "memory");
>>>           asm volatile("msr tcr_el1, %0" : : "r" (tcr) : "memory");
>>>           asm volatile("msr mair_el1, %0" : : "r" (attr) : "memory");
>>> -    } else if (el == 2) {
>>> -        asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
>>> -        asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
>>> -        asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
>>> -    } else if (el == 3) {
>>> +        break;
>>> +    case 3:
>>>           asm volatile("msr ttbr0_el3, %0" : : "r" (table) : "memory");
>>>           asm volatile("msr tcr_el3, %0" : : "r" (tcr) : "memory");
>>>           asm volatile("msr mair_el3, %0" : : "r" (attr) : "memory");
>>> -    } else {
>>> +
>>> +        /* We may switch to EL2 later, so set those too; fall through */
>>> +    case 2:
>>> +        asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
>>> +        asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
>>> +        asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
>>> +        break;
>>
>>
>> This may be problematic. If we use secure memory for EL3, the MMU tables
>> have to be within the secure memory. But EL2 will not be able to access
>> it. I believe you have verified this patch set actually work. I am
>> curious how it work.
>
> That's a good question. I suppose the default config doesn't actually lock secure memory? Or doesn't go secure at all?
>

The patch set using this secure memory is still pending. Our internal 
team has been working on it. So the secure memory has been working. I am 
sure I have put MMU tables in secure memory. You can verify by running 
"bdi" command. It will show you the secure memory location. If you don't 
see it, then you don't have secure memory setup. By default, it is enabled.

I remember I have done a test to access to the secure memory from 
non-secure master and got an exception.

Could your test run at EL2 without a proper MMU table? I don't remember 
if the core would hang, or continue to run if fetching MMU table fails.

York