[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[Alexander Graf]

On 18/10/2016 17:46, york sun wrote:
> On 10/17/2016 02:11 AM, Alexander Graf wrote:
>>
>>
>> On 15.10.16 18:58, york sun wrote:
>>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>>>> reserve some memory that U-Boot is aware of as secure.
>>>>
>>>> For those systems, mask out that secure memory in the EFI memory map,
>>>> as it's not usable from EL2 or EL1.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>>>
>>>> ---
>>>>
>>>> v4 -> v5:
>>>>
>>>>   - Use gd->arch.secure_ram
>>>> ---
>>>>  lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>>>>  1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>>> index 95aa590..4966e48 100644
>>>> --- a/lib/efi_loader/efi_memory.c
>>>> +++ b/lib/efi_loader/efi_memory.c
>>>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>>>  	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>>>  #endif
>>>>
>>>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>>> +	/* Declare secure ram as reserved */
>>>> +        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>>>> +		uint64_t secure_start = gd->arch.secure_ram;
>>>> +		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>>>> +
>>>> +		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>>>> +		secure_start &= ~EFI_PAGE_MASK;
>>>> +		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>>>> +
>>>> +		efi_add_memory_map(secure_start, secure_pages,
>>>> +				   EFI_RESERVED_MEMORY_TYPE, false);
>>>> +        }
>>>> +#endif
>>>> +
>>>>  	return 0;
>>>>  }
>>>>
>>>
>>> Alex,
>>>
>>> Do you see any issue without this patch? The secure memory is not
>>> visible to OS. gd->ram_size is reduced to hide the secure memory.
>>
>> We're building the memory map out of gd->bd->bi_dram rather than
>> ram_size, because it's perfectly reasonable for systems to have memory
>> holes.
>>
>> So even if we're adjusting gd->ram_size, the OS will still see secure
>> memory. In fact, doesn't bootm do that as well?
>>
>> arch/arm/lib/bootm-fdt.c:       ret = fdt_fixup_memory_banks(blob,
>> start, size, CONFIG_NR_DRAM_BANKS);
>>
>> On armv7, arch_fixup_fdt() removes the secure memory region from the
>> edge of a memory bank. But on armv8 I don't see anything like it?
>>
> 
> Alex,
> 
> For ARMv8, our SoCs have several regions. Depends on the board 
> implementation, the memory may end up in different banks. See 
> board/freescale/ls2080ardb/ddr.c for example. The secure ram is already 
> carved out.

Ok, I think you're right. I'll remove this patch. See below for
"lsefimmap" output from grub2 with and without the patch applied.


Alex


With patch:

Type      Physical start  - end             #Pages        Size Attributes
MMIO      0000000001e60000-0000000001e60fff 00000001      4KiB RT
conv-mem  0000000080000000-0000000087ffffff 00008000    128MiB WB
BS-data   0000000088000000-0000000088003fff 00000004     16KiB WB
conv-mem  0000000088006000-00000000fab33fff 00072b2e 1879224KiB WB
RT-data   00000000fab34000-00000000fab34fff 00000001      4KiB RT WB
ldr-data  00000000fab35000-00000000fad0dfff 000001d9   1892KiB WB
ldr-data  00000000fad0e000-00000000fed0dfff 00004000     64MiB WB
ldr-data  00000000fed0e000-00000000fff14fff 00001207  18460KiB WB
reserved  00000000fff156b0-00000000fff166af 00000001      4KiB WB
ldr-data  00000000fff166b0-00000000fffa46af 0000008e    568KiB WB
RT-code   00000000fffa5000-00000000fffa5fff 00000001      4KiB RT WB
ldr-data  00000000fffa6000-00000000ffffffff 0000005a    360KiB WB
reserved  0000006000000000-00000060ffffffff 00100000      4GiB WB
conv-mem  0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data  000000835bffa000-00000083bfff9fff 00064000   1600MiB WB
conv-mem  00000083bfffa000-00000083bfffffff 00000006     24KiB WB
reserved  00000083ffe00000-00000083ffffffff 00000200      2MiB WB

Without patch:

Type      Physical start  - end             #Pages        Size Attributes
MMIO      0000000001e60000-0000000001e60fff 00000001      4KiB RT
conv-mem  0000000080000000-0000000087ffffff 00008000    128MiB WB
BS-data   0000000088000000-0000000088003fff 00000004     16KiB WB
conv-mem  0000000088006000-00000000fab34fff 00072b2f 1879228KiB WB
RT-data   00000000fab35000-00000000fab35fff 00000001      4KiB RT WB
ldr-data  00000000fab36000-00000000fad0efff 000001d9   1892KiB WB
ldr-data  00000000fad0f000-00000000fed0efff 00004000     64MiB WB
ldr-data  00000000fed0f000-00000000fff15fff 00001207  18460KiB WB
reserved  00000000fff166b0-00000000fff176af 00000001      4KiB WB
ldr-data  00000000fff176b0-00000000fffa46af 0000008d    564KiB WB
RT-code   00000000fffa5000-00000000fffa5fff 00000001      4KiB RT WB
ldr-data  00000000fffa6000-00000000ffffffff 0000005a    360KiB WB
reserved  0000006000000000-00000060ffffffff 00100000      4GiB WB
conv-mem  0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data  000000835bffa000-00000083bfff9fff 00064000   1600MiB WB
conv-mem  00000083bfffa000-00000083bfffffff 00000006     24KiB WB