| Message ID | 1476525795-27483-8-git-send-email-agraf@suse.de |
|---|---|
| State | Superseded |
| Delegated to: | Alexander Graf |
| Headers | show |
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@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. York
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@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
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@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. York
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@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
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; }
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@suse.de> --- v4 -> v5: - Use gd->arch.secure_ram --- lib/efi_loader/efi_memory.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)