Re: [RFC PATCH] arm64/efi: use id mapping for Runtime Services

2014-08-06 Thread Ard Biesheuvel
On 6 August 2014 16:36, Will Deacon will.dea...@arm.com wrote:
 On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
 There are 2 interesting pieces of information in the UEFI spec section 2.3.6
 regarding the mapping of runtime regions:
 (a) the firmware should not request a virtual mapping for configuration 
 tables,
 even though they are marked as EfiRuntimeServicesData;
 (b) calling SetVirtualAddressMap() is optional, and it is equally 
 appropriate to
 call Runtime Services using an identity mapping.

 So we can eliminate some of the complexity around UEFI Runtime Services by 
 not
 using a virtual mapping at all, and calling the services at their physical
 address. This is especially useful under kexec, as SetVirtualAddressMap() may
 only be called once, and there is no guarantee that mappings are stable 
 between
 different kexec'd kernels.

 The fallout for other in-kernel users of UEFI data structures should be
 negligible, as they cannot legally access those data structures through
 pre-existing virtual mappings anyway (point (a) above)

 It should also be noted that, as the kernel side of the address space 
 (TTBR1) is
 retained, the stack and pointer function arguments remain accessible to the
 runtime service while the id mapping is active.

 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  arch/arm64/include/asm/efi.h |  24 --
  arch/arm64/kernel/efi.c  | 106 
 ++-
  2 files changed, 23 insertions(+), 107 deletions(-)

 diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
 index a34fd3b12e2b..d42a21e79b39 100644
 --- a/arch/arm64/include/asm/efi.h
 +++ b/arch/arm64/include/asm/efi.h
 @@ -1,8 +1,10 @@
  #ifndef _ASM_EFI_H
  #define _ASM_EFI_H

 +#include asm/cacheflush.h
  #include asm/io.h
  #include asm/neon.h
 +#include asm/tlbflush.h

  #ifdef CONFIG_EFI
  extern void efi_init(void);
 @@ -12,23 +14,37 @@ extern void efi_idmap_init(void);
  #define efi_idmap_init()
  #endif

 +static inline void switch_pgd(pgd_t *pgd, struct mm_struct *mm)
 +{
 + cpu_switch_mm(pgd, mm);
 + flush_tlb_all();
 + if (icache_is_aivivt())
 + __flush_icache_all();
 +}
 +
  #define efi_call_virt(f, ...)   
  \
  ({   \
 - efi_##f##_t *__f = efi.systab-runtime-f;  \
 + efi_##f##_t *__f;   \
   efi_status_t __s;   \
   \
 - kernel_neon_begin();\
 + kernel_neon_begin(); /* disables preemption */  \
 + switch_pgd(idmap_pg_dir, init_mm); \
 + __f =  efi.systab-runtime-f;  \
   __s = __f(__VA_ARGS__); \
 + switch_pgd(current-active_mm-pgd, current-active_mm);\
   kernel_neon_end();  \
   __s;\
  })

 This scares the bejesus out of me, but I can't put my finger on exactly why.
 I think it does what you intend and I can't break it myself, so it would be
 really good if the EFI folks could confirm that this looks good to them.


There is something similar in the x86 code (arch/x86/platform/efi/efi.c)

 * The new method does a pagetable switch in a preemption-safe manner
 * so that we're in a different address space when calling a runtime
 * function. For function arguments passing we do copy the PGDs of the
 * kernel page table into -trampoline_pgd prior to each call.


How exactly this will turn out for arm64 (and ARM) is still under
discussion, though. My position is that if you are going to switch
pgd's anyway, why not just use the id mapping? And even if you feel it
is mandatory to install a virtual address mapping into UEFI (which I
think is /not/ the case), you could install an id mapping as well,
which means all the related machinery still gets invoked.
The alternative to using a TTBR0 mapping would be to reserve a slice
of kernel virtual memory so that the Runtime Services are guaranteed
to live at the same virtual address after a kexec, ideally the same
region on 4k and 64k pages ...

We are planning to discuss this further at Linaro Connect next month.

-- 
Ard.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH] arm64/efi: use id mapping for Runtime Services

2014-08-06 Thread Will Deacon
On Wed, Aug 06, 2014 at 04:15:23PM +0100, Ard Biesheuvel wrote:
 On 6 August 2014 16:36, Will Deacon will.dea...@arm.com wrote:
  On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
   #define efi_call_virt(f, ...) 
 \
   ({   \
  - efi_##f##_t *__f = efi.systab-runtime-f;  \
  + efi_##f##_t *__f;   \
efi_status_t __s;   \
\
  - kernel_neon_begin();\
  + kernel_neon_begin(); /* disables preemption */  \
  + switch_pgd(idmap_pg_dir, init_mm); \
  + __f =  efi.systab-runtime-f;  \
__s = __f(__VA_ARGS__); \
  + switch_pgd(current-active_mm-pgd, current-active_mm);\
kernel_neon_end();  \
__s;\
   })
 
  This scares the bejesus out of me, but I can't put my finger on exactly why.
  I think it does what you intend and I can't break it myself, so it would be
  really good if the EFI folks could confirm that this looks good to them.
 
 
 There is something similar in the x86 code (arch/x86/platform/efi/efi.c)
 
  * The new method does a pagetable switch in a preemption-safe manner
  * so that we're in a different address space when calling a runtime
  * function. For function arguments passing we do copy the PGDs of the
  * kernel page table into -trampoline_pgd prior to each call.
 
 
 How exactly this will turn out for arm64 (and ARM) is still under
 discussion, though. My position is that if you are going to switch
 pgd's anyway, why not just use the id mapping? And even if you feel it
 is mandatory to install a virtual address mapping into UEFI (which I
 think is /not/ the case), you could install an id mapping as well,
 which means all the related machinery still gets invoked.
 The alternative to using a TTBR0 mapping would be to reserve a slice
 of kernel virtual memory so that the Runtime Services are guaranteed
 to live at the same virtual address after a kexec, ideally the same
 region on 4k and 64k pages ...
 
 We are planning to discuss this further at Linaro Connect next month.

Ok, thanks for the update. I'll hold off on this until you've discussed it
some more.

Cheers,

Will
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFC PATCH] arm64/efi: use id mapping for Runtime Services

2014-07-31 Thread Ard Biesheuvel
There are 2 interesting pieces of information in the UEFI spec section 2.3.6
regarding the mapping of runtime regions:
(a) the firmware should not request a virtual mapping for configuration tables,
even though they are marked as EfiRuntimeServicesData;
(b) calling SetVirtualAddressMap() is optional, and it is equally appropriate to
call Runtime Services using an identity mapping.

So we can eliminate some of the complexity around UEFI Runtime Services by not
using a virtual mapping at all, and calling the services at their physical
address. This is especially useful under kexec, as SetVirtualAddressMap() may
only be called once, and there is no guarantee that mappings are stable between
different kexec'd kernels.

The fallout for other in-kernel users of UEFI data structures should be
negligible, as they cannot legally access those data structures through
pre-existing virtual mappings anyway (point (a) above)

It should also be noted that, as the kernel side of the address space (TTBR1) is
retained, the stack and pointer function arguments remain accessible to the
runtime service while the id mapping is active.

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/arm64/include/asm/efi.h |  24 --
 arch/arm64/kernel/efi.c  | 106 ++-
 2 files changed, 23 insertions(+), 107 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index a34fd3b12e2b..d42a21e79b39 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -1,8 +1,10 @@
 #ifndef _ASM_EFI_H
 #define _ASM_EFI_H
 
+#include asm/cacheflush.h
 #include asm/io.h
 #include asm/neon.h
+#include asm/tlbflush.h
 
 #ifdef CONFIG_EFI
 extern void efi_init(void);
@@ -12,23 +14,37 @@ extern void efi_idmap_init(void);
 #define efi_idmap_init()
 #endif
 
+static inline void switch_pgd(pgd_t *pgd, struct mm_struct *mm)
+{
+   cpu_switch_mm(pgd, mm);
+   flush_tlb_all();
+   if (icache_is_aivivt())
+   __flush_icache_all();
+}
+
 #define efi_call_virt(f, ...)  \
 ({ \
-   efi_##f##_t *__f = efi.systab-runtime-f;  \
+   efi_##f##_t *__f;   \
efi_status_t __s;   \
\
-   kernel_neon_begin();\
+   kernel_neon_begin(); /* disables preemption */  \
+   switch_pgd(idmap_pg_dir, init_mm); \
+   __f =  efi.systab-runtime-f;  \
__s = __f(__VA_ARGS__); \
+   switch_pgd(current-active_mm-pgd, current-active_mm);\
kernel_neon_end();  \
__s;\
 })
 
 #define __efi_call_virt(f, ...)
\
 ({ \
-   efi_##f##_t *__f = efi.systab-runtime-f;  \
+   efi_##f##_t *__f;   \
\
-   kernel_neon_begin();\
+   kernel_neon_begin(); /* disables preemption */  \
+   switch_pgd(idmap_pg_dir, init_mm); \
+   __f =  efi.systab-runtime-f;  \
__f(__VA_ARGS__);   \
+   switch_pgd(current-active_mm-pgd, current-active_mm);\
kernel_neon_end();  \
 })
 
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index e72f3100958f..d620a031e7bf 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -27,8 +27,6 @@
 
 struct efi_memory_map memmap;
 
-static efi_runtime_services_t *runtime;
-
 static u64 efi_system_table;
 
 static int uefi_debug __initdata;
@@ -340,51 +338,9 @@ void __init efi_idmap_init(void)
efi_setup_idmap();
 }
 
-static int __init remap_region(efi_memory_desc_t *md, void **new)
-{
-   u64 paddr, vaddr, npages, size;
-
-   paddr = md-phys_addr;
-   npages = md-num_pages;
-   memrange_efi_to_native(paddr, npages);
-   size = npages  PAGE_SHIFT;
-
-   if (is_normal_ram(md))
-   vaddr = (__force u64)ioremap_cache(paddr, size);
-   else
-   vaddr = (__force u64)ioremap(paddr, size);
-
-   if (!vaddr) {
-   pr_err(Unable to remap 0x%llx pages @ %p\n,
-  npages, (void *)paddr);
-   return 0;
-   }
-
-   

Re: [RFC PATCH] arm64/efi: use id mapping for Runtime Services

2014-07-31 Thread Mark Salter
On Thu, 2014-07-31 at 16:11 +0200, Ard Biesheuvel wrote:
 There are 2 interesting pieces of information in the UEFI spec section 2.3.6
 regarding the mapping of runtime regions:
 (a) the firmware should not request a virtual mapping for configuration 
 tables,
 even though they are marked as EfiRuntimeServicesData;
 (b) calling SetVirtualAddressMap() is optional, and it is equally appropriate 
 to
 call Runtime Services using an identity mapping.
 
 So we can eliminate some of the complexity around UEFI Runtime Services by not
 using a virtual mapping at all, and calling the services at their physical
 address. This is especially useful under kexec, as SetVirtualAddressMap() may
 only be called once, and there is no guarantee that mappings are stable 
 between
 different kexec'd kernels.
 
 The fallout for other in-kernel users of UEFI data structures should be
 negligible, as they cannot legally access those data structures through
 pre-existing virtual mappings anyway (point (a) above)
 
 It should also be noted that, as the kernel side of the address space (TTBR1) 
 is
 retained, the stack and pointer function arguments remain accessible to the
 runtime service while the id mapping is active.
 
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  arch/arm64/include/asm/efi.h |  24 --
  arch/arm64/kernel/efi.c  | 106 
 ++-
  2 files changed, 23 insertions(+), 107 deletions(-)
 
 diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
 index a34fd3b12e2b..d42a21e79b39 100644
 --- a/arch/arm64/include/asm/efi.h
 +++ b/arch/arm64/include/asm/efi.h
 @@ -1,8 +1,10 @@
  #ifndef _ASM_EFI_H
  #define _ASM_EFI_H
  
 +#include asm/cacheflush.h
  #include asm/io.h
  #include asm/neon.h
 +#include asm/tlbflush.h
  
  #ifdef CONFIG_EFI
  extern void efi_init(void);
 @@ -12,23 +14,37 @@ extern void efi_idmap_init(void);
  #define efi_idmap_init()
  #endif
  
 +static inline void switch_pgd(pgd_t *pgd, struct mm_struct *mm)
 +{
 + cpu_switch_mm(pgd, mm);
 + flush_tlb_all();
 + if (icache_is_aivivt())
 + __flush_icache_all();
 +}
 +
  #define efi_call_virt(f, ...)
 \
  ({   \
 - efi_##f##_t *__f = efi.systab-runtime-f;  \
 + efi_##f##_t *__f;   \
   efi_status_t __s;   \
   \
 - kernel_neon_begin();\
 + kernel_neon_begin(); /* disables preemption */  \
 + switch_pgd(idmap_pg_dir, init_mm); \
 + __f =  efi.systab-runtime-f;  \
   __s = __f(__VA_ARGS__); \
 + switch_pgd(current-active_mm-pgd, current-active_mm);\
   kernel_neon_end();  \
   __s;\
  })
  
  #define __efi_call_virt(f, ...)  
 \
  ({   \
 - efi_##f##_t *__f = efi.systab-runtime-f;  \
 + efi_##f##_t *__f;   \
   \
 - kernel_neon_begin();\
 + kernel_neon_begin(); /* disables preemption */  \
 + switch_pgd(idmap_pg_dir, init_mm); \
 + __f =  efi.systab-runtime-f;  \
   __f(__VA_ARGS__);   \
 + switch_pgd(current-active_mm-pgd, current-active_mm);\
   kernel_neon_end();  \
  })

If you replace the current user pgd with idmap pgd and there is
an exception in the firmware which would lead to the user task
being killed, what happens?

  
 diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
 index e72f3100958f..d620a031e7bf 100644
 --- a/arch/arm64/kernel/efi.c
 +++ b/arch/arm64/kernel/efi.c
 @@ -27,8 +27,6 @@
  
  struct efi_memory_map memmap;
  
 -static efi_runtime_services_t *runtime;
 -
  static u64 efi_system_table;
  
  static int uefi_debug __initdata;
 @@ -340,51 +338,9 @@ void __init efi_idmap_init(void)
   efi_setup_idmap();
  }
  
 -static int __init remap_region(efi_memory_desc_t *md, void **new)
 -{
 - u64 paddr, vaddr, npages, size;
 -
 - paddr = md-phys_addr;
 - npages = md-num_pages;
 - memrange_efi_to_native(paddr, npages);
 - size = npages  PAGE_SHIFT;
 -
 - if (is_normal_ram(md))
 - vaddr = (__force