1. 14 Jun, 2018 1 commit
  2. 21 Aug, 2017 2 commits
    • Ard Biesheuvel's avatar
      efi/arm/arm64: Add missing assignment of efi.config_table · 9a9de5c0
      Ard Biesheuvel authored
      
      
      The ARM EFI init code never assigns the config_table member of the
      efi struct, which means the sysfs device node is missing, and other
      in-kernel users will not work correctly. So add the missing assignment.
      
      Note that, for now, the runtime and fw_vendor members are still
      omitted. This is deliberate: exposing physical addresses via sysfs nodes
      encourages behavior that we would like to avoid on ARM (given how it is
      more finicky about using correct memory attributes when mapping memory
      in userland that may be mapped by the kernel already as well).
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170818194947.19347-6-ard.biesheuvel@linaro.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9a9de5c0
    • Ard Biesheuvel's avatar
      efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP · f56ab9a5
      Ard Biesheuvel authored
      
      
      On ARM, regions of memory that are described by UEFI as having special
      significance to the firmware itself are omitted from the linear mapping.
      This is necessary since we cannot guarantee that alternate mappings of
      the same physical region will use attributes that are compatible with
      the ones we use for the linear mapping, and aliases with mismatched
      attributes are prohibited by the architecture.
      
      The above does not apply to ACPI reclaim regions: such regions have no
      special significance to the firmware, and it is up to the OS to decide
      whether or not to preserve them after it has consumed their contents,
      and for how long, after which time the OS can use the memory in any way
      it likes. In the Linux case, such regions are preserved indefinitely,
      and are simply treated the same way as other 'reserved' memory types.
      
      Punching holes into the linear mapping causes page table fragmentation,
      which increases TLB pressure, and so we should avoid doing so if we can.
      So add a special case for regions of type EFI_ACPI_RECLAIM_MEMORY, and
      memblock_reserve() them instead of marking them MEMBLOCK_NOMAP.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: Mark Rutland's avatarMark Rutland <mark.rutland@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170818194947.19347-2-ard.biesheuvel@linaro.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f56ab9a5
  3. 01 Feb, 2017 1 commit
  4. 18 Oct, 2016 1 commit
  5. 09 Sep, 2016 3 commits
    • Ard Biesheuvel's avatar
      efi/arm64: Treat regions with WT/WC set but WB cleared as memory · cb82cce7
      Ard Biesheuvel authored
      
      
      Currently, memory regions are only recorded in the memblock memory table
      if they have the EFI_MEMORY_WB memory type attribute set. In case the
      region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
      will leave it out of the linear mapping.
      
      However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
      attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
      question is obviously backed by normal memory, but is not recorded in the
      memblock memory table at all. Since it would be useful to be able to
      identify any UEFI reported memory region using memblock_is_memory(), it
      makes sense to add all memory to the memblock memory table, and simply mark
      it as MEMBLOCK_NOMAP if it lacks the EFI_MEMORY_WB attribute.
      
      While implementing this, let's refactor the code slightly to make it easier
      to understand: replace is_normal_ram() with is_memory(), and make it return
      true for each region that has any of the WB|WT|WC bits set. (This follows
      the AArch64 bindings in the UEFI spec, which state that those are the
      attributes that map to normal memory)
      
      Also, replace is_reserve_region() with is_usable_memory(), and only invoke
      it if the region in question was identified as memory by is_memory() in the
      first place. The net result is the same (only reserved regions that are
      backed by memory end up in the memblock memory table with the MEMBLOCK_NOMAP
      flag set) but carried out in a more straightforward way.
      
      Finally, we remove the trailing asterisk in the EFI debug output. Keeping it
      clutters the code, and it serves no real purpose now that we no longer
      temporarily reserve BootServices code and data regions like we did in the
      early days of EFI support on arm64 Linux (which it inherited from the x86
      implementation)
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarLeif Lindholm <leif.lindholm@linaro.org>
      Tested-by: James Morse's avatarJames Morse <james.morse@arm.com>
      Reviewed-by: James Morse's avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      cb82cce7
    • Ard Biesheuvel's avatar
      efi/arm*: esrt: Add missing call to efi_esrt_init() · 2ead3084
      Ard Biesheuvel authored
      
      
      ESRT support is built by default for all architectures that define
      CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
      since efi_esrt_init() was never called. So add the missing call.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Jones <pjones@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      2ead3084
    • Matt Fleming's avatar
      efi: Refactor efi_memmap_init_early() into arch-neutral code · 9479c7ce
      Matt Fleming authored
      
      
      Every EFI architecture apart from ia64 needs to setup the EFI memory
      map at efi.memmap, and the code for doing that is essentially the same
      across all implementations. Therefore, it makes sense to factor this
      out into the common code under drivers/firmware/efi/.
      
      The only slight variation is the data structure out of which we pull
      the initial memory map information, such as physical address, memory
      descriptor size and version, etc. We can address this by passing a
      generic data structure (struct efi_memory_map_data) as the argument to
      efi_memmap_init_early() which contains the minimum info required for
      initialising the memory map.
      
      In the process, this patch also fixes a few undesirable implementation
      differences:
      
       - ARM and arm64 were failing to clear the EFI_MEMMAP bit when
         unmapping the early EFI memory map. EFI_MEMMAP indicates whether
         the EFI memory map is mapped (not the regions contained within) and
         can be traversed.  It's more correct to set the bit as soon as we
         memremap() the passed in EFI memmap.
      
       - Rename efi_unmmap_memmap() to efi_memmap_unmap() to adhere to the
         regular naming scheme.
      
      This patch also uses a read-write mapping for the memory map instead
      of the read-only mapping currently used on ARM and arm64. x86 needs
      the ability to update the memory map in-place when assigning virtual
      addresses to regions (efi_map_region()) and tagging regions when
      reserving boot services (efi_reserve_boot_services()).
      
      There's no way for the generic fake_mem code to know which mapping to
      use without introducing some arch-specific constant/hook, so just use
      read-write since read-only is of dubious value for the EFI memory map.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      9479c7ce
  6. 03 Jun, 2016 1 commit
    • Dennis Chen's avatar
      efi/arm: Fix the format of EFI debug messages · c7534397
      Dennis Chen authored
      
      
      When both EFI and memblock debugging is enabled on the kernel command line:
      
        'efi=debug memblock=debug'
      
      .. the debug messages for early_con look the following way:
      
       [    0.000000] efi:   0x0000e1050000-0x0000e105ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x0000e1300000-0x0000e1300fff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x0000e8200000-0x0000e827ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x008000000000-0x008001e7ffff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]
       [    0.000000] memblock_add: [0x00008000000000-0x00008001e7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
       [    0.000000] *
       ...
      
      Note the misplaced '*' line, which happened because the memblock debug message
      was printed while the EFI debug message was still being constructed..
      
      This patch fixes the output to be the expected:
      
       [    0.000000] efi:   0x0000e1050000-0x0000e105ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x0000e1300000-0x0000e1300fff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x0000e8200000-0x0000e827ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
       [    0.000000] efi:   0x008000000000-0x008001e7ffff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
       [    0.000000] memblock_add: [0x00008000000000-0x00008001e7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
       ...
      
      Note how the '*' is now in the proper EFI debug message line.
      Signed-off-by: default avatarDennis Chen <dennis.chen@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Acked-by: Mark Rutland's avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steve Capper <steve.capper@arm.com>
      Cc: Steve McIntyre <steve@einval.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1464690224-4503-3-git-send-email-matt@codeblueprint.co.uk
      
      
      [ Made the changelog more readable. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c7534397
  7. 28 Apr, 2016 8 commits
  8. 19 Apr, 2016 1 commit
    • Arnd Bergmann's avatar
      efi: ARM: avoid warning about phys_addr_t cast · 7464b6e3
      Arnd Bergmann authored
      memblock_remove() takes a phys_addr_t, which may be narrower than 64 bits,
      causing a harmless warning:
      
      drivers/firmware/efi/arm-init.c: In function 'reserve_regions':
      include/linux/kernel.h:29:20: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
       #define ULLONG_MAX (~0ULL)
                          ^
      drivers/firmware/efi/arm-init.c:152:21: note: in expansion of macro 'ULLONG_MAX'
        memblock_remove(0, ULLONG_MAX);
      
      This adds an explicit typecast to avoid the warning
      
      Fixes: 500899c2
      
       ("efi: ARM/arm64: ignore DT memory nodes instead of removing them")
      Acked-by Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7464b6e3
  9. 15 Apr, 2016 1 commit
  10. 31 Mar, 2016 1 commit
    • Ard Biesheuvel's avatar
      efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping · 7cc8cbcf
      Ard Biesheuvel authored
      Commit 4dffbfc4 ("arm64/efi: mark UEFI reserved regions as
      MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices
      regions as well as the kernel's copy of the UEFI memory map to set the
      MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the
      kernel direct mapping, and from being covered by a struct page.
      For the RuntimeServices regions, this is an obvious win, since the contents
      of these regions have significance to the firmware executable code itself,
      and are mapped in the EFI page tables using attributes that are described in
      the UEFI memory map, and which may differ from the attributes we use for
      mapping system RAM. It also prevents the contents from being modified
      inadvertently, since the EFI page tables are only live during runtime
      service invocations.
      
      None of these concerns apply to the allocation that covers the UEFI memory
      map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on
      the region did allow us to use ioremap_cache() to map it both on arm64 and
      on ARM, since the latter does not allow ioremap_cache() to be used on
      regions that are covered by a struct page.
      
      The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe,
      but in the mean time, it has been reported that commit 4dffbfc4 causes
      a regression on 64k granule kernels. This is due to the fact that, given
      the 64 KB page size, the region that we end up removing from the kernel
      direct mapping is rounded up to 64 KB, and this 64 KB page frame may be
      shared with the initrd when booting via GRUB (which does not align its
      EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash
      the kernel as soon as it tries to access the initrd.
      
      Since the issue is specific to arm64, revert back to memblock_reserve()'ing
      the UEFI memory map when running on arm64. This is a temporary fix for v4.5
      and v4.6, and will be superseded in the v4.7 timeframe when we will be able
      to move back to memblock_reserve() unconditionally.
      
      Fixes: 4dffbfc4
      
       ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Mark Langsdorf <mlangsdo@redhat.com>
      Cc: <stable@vger.kernel.org> # v4.5
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      7cc8cbcf
  11. 22 Feb, 2016 1 commit
  12. 09 Dec, 2015 3 commits
  13. 26 Nov, 2015 2 commits
  14. 25 Nov, 2015 1 commit
    • Mark Rutland's avatar
      arm64: efi: correctly map runtime regions · 3b12acf4
      Mark Rutland authored and Catalin Marinas's avatar Catalin Marinas committed
      
      
      The kernel may use a page granularity of 4K, 16K, or 64K depending on
      configuration.
      
      When mapping EFI runtime regions, we use memrange_efi_to_native to round
      the physical base address of a region down to a kernel page boundary,
      and round the size up to a kernel page boundary, adding the residue left
      over from rounding down the physical base address. We do not round down
      the virtual base address.
      
      In __create_mapping we account for the offset of the virtual base from a
      granule boundary, adding the residue to the size before rounding the
      base down to said granule boundary.
      
      Thus we account for the residue twice, and when the residue is non-zero
      will cause __create_mapping to map an additional page at the end of the
      region. Depending on the memory map, this page may be in a region we are
      not intended/permitted to map, or may clash with a different region that
      we wish to map. In typical cases, mapping the next item in the memory
      map will overwrite the erroneously created entry, as we sort the memory
      map in the stub.
      
      As __create_mapping can cope with base addresses which are not page
      aligned, we can instead rely on it to map the region appropriately, and
      simplify efi_virtmap_init by removing the unnecessary code.
      Signed-off-by: Mark Rutland's avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: Catalin Marinas's avatarCatalin Marinas <catalin.marinas@arm.com>
      3b12acf4
  15. 18 Nov, 2015 1 commit
  16. 28 Oct, 2015 1 commit
    • Ard Biesheuvel's avatar
      efi: Use correct type for struct efi_memory_map::phys_map · 44511fb9
      Ard Biesheuvel authored
      We have been getting away with using a void* for the physical
      address of the UEFI memory map, since, even on 32-bit platforms
      with 64-bit physical addresses, no truncation takes place if the
      memory map has been allocated by the firmware (which only uses
      1:1 virtually addressable memory), which is usually the case.
      
      However, commit:
      
        0f96a99d
      
       ("efi: Add "efi_fake_mem" boot option")
      
      adds code that clones and modifies the UEFI memory map, and the
      clone may live above 4 GB on 32-bit platforms.
      
      This means our use of void* for struct efi_memory_map::phys_map has
      graduated from 'incorrect but working' to 'incorrect and
      broken', and we need to fix it.
      
      So redefine struct efi_memory_map::phys_map as phys_addr_t, and
      get rid of a bunch of casts that are now unneeded.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: izumi.taku@jp.fujitsu.com
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: linux-efi@vger.kernel.org
      Cc: matt.fleming@intel.com
      Link: http://lkml.kernel.org/r/1445593697-1342-1-git-send-email-ard.biesheuvel@linaro.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      44511fb9
  17. 12 Oct, 2015 2 commits
  18. 07 Oct, 2015 2 commits
  19. 01 Oct, 2015 1 commit
    • Ard Biesheuvel's avatar
      arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions · 0ce3cc00
      Ard Biesheuvel authored
      
      
      The new Properties Table feature introduced in UEFIv2.5 may
      split memory regions that cover PE/COFF memory images into
      separate code and data regions. Since these regions only differ
      in the type (runtime code vs runtime data) and the permission
      bits, but not in the memory type attributes (UC/WC/WT/WB), the
      spec does not require them to be aligned to 64 KB.
      
      Since the relative offset of PE/COFF .text and .data segments
      cannot be changed on the fly, this means that we can no longer
      pad out those regions to be mappable using 64 KB pages.
      Unfortunately, there is no annotation in the UEFI memory map
      that identifies data regions that were split off from a code
      region, so we must apply this logic to all adjacent runtime
      regions whose attributes only differ in the permission bits.
      
      So instead of rounding each memory region to 64 KB alignment at
      both ends, only round down regions that are not directly
      preceded by another runtime region with the same type
      attributes. Since the UEFI spec does not mandate that the memory
      map be sorted, this means we also need to sort it first.
      
      Note that this change will result in all EFI_MEMORY_RUNTIME
      regions whose start addresses are not aligned to the OS page
      size to be mapped with executable permissions (i.e., on kernels
      compiled with 64 KB pages). However, since these mappings are
      only active during the time that UEFI Runtime Services are being
      invoked, the window for abuse is rather small.
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Reviewed-by: default avatarMark Salter <msalter@redhat.com>
      Reviewed-by: Mark Rutland's avatarMark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org> # v4.0+
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0ce3cc00
  20. 27 Jul, 2015 1 commit
  21. 28 May, 2015 1 commit
    • Dan Williams's avatar
      e820, efi: add ACPI 6.0 persistent memory types · ad5fb870
      Dan Williams authored
      
      
      ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
      Mark it "reserved" and allow it to be claimed by a persistent memory
      device driver.
      
      This definition is in addition to the Linux kernel's existing type-12
      definition that was recently added in support of shipping platforms with
      NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
      OEM reserved).
      
      Note, /proc/iomem can be consulted for differentiating legacy
      "Persistent Memory (legacy)" E820_PRAM vs standard "Persistent Memory"
      E820_PMEM.
      
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      ad5fb870
  22. 20 Mar, 2015 1 commit
    • Will Deacon's avatar
      arm64: efi: don't restore TTBR0 if active_mm points at init_mm · 130c93fd
      Will Deacon authored and Catalin Marinas's avatar Catalin Marinas committed
      
      
      init_mm isn't a normal mm: it has swapper_pg_dir as its pgd (which
      contains kernel mappings) and is used as the active_mm for the idle
      thread.
      
      When restoring the pgd after an EFI call, we write current->active_mm
      into TTBR0. If the current task is actually the idle thread (e.g. when
      initialising the EFI RTC before entering userspace), then the TLB can
      erroneously populate itself with junk global entries as a result of
      speculative table walks.
      
      When we do eventually return to userspace, the task can end up hitting
      these junk mappings leading to lockups, corruption or crashes.
      
      This patch fixes the problem in the same way as the CPU suspend code by
      ensuring that we never switch to the init_mm in efi_set_pgd and instead
      point TTBR0 at the zero page. A check is also added to cpu_switch_mm to
      BUG if we get passed swapper_pg_dir.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Fixes: f3cdfd23
      
       ("arm64/efi: move SetVirtualAddressMap() to UEFI stub")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: Catalin Marinas's avatarCatalin Marinas <catalin.marinas@arm.com>
      130c93fd
  23. 14 Mar, 2015 1 commit
  24. 22 Jan, 2015 1 commit
  25. 16 Jan, 2015 1 commit