1. 18 Nov, 2015 1 commit
  2. 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.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      44511fb9
  3. 12 Oct, 2015 2 commits
  4. 07 Oct, 2015 2 commits
  5. 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: default 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0ce3cc00
  6. 27 Jul, 2015 1 commit
  7. 27 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
  8. 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
      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: default avatarCatalin Marinas <catalin.marinas@arm.com>
      130c93fd
  9. 14 Mar, 2015 1 commit
  10. 22 Jan, 2015 1 commit
  11. 16 Jan, 2015 1 commit
  12. 12 Jan, 2015 3 commits
  13. 08 Jan, 2015 1 commit
    • Ard Biesheuvel's avatar
      arm64/efi: add missing call to early_ioremap_reset() · 0e63ea48
      Ard Biesheuvel authored
      The early ioremap support introduced by patch bf4b558e
      ("arm64: add early_ioremap support") failed to add a call to
      early_ioremap_reset() at an appropriate time. Without this call,
      invocations of early_ioremap etc. that are done too late will go
      unnoticed and may cause corruption.
      
      This is exactly what happened when the first user of this feature
      was added in patch f84d0275 ("arm64: add EFI runtime services").
      The early mapping of the EFI memory map is unmapped during an early
      initcall, at which time the early ioremap support is long gone.
      
      Fix by adding the missing call to early_ioremap_reset() to
      setup_arch(), and move the offending early_memunmap() to right after
      the point where the early mapping of the EFI memory map is last used.
      
      Fixes: f84d0275 ("arm64: add EFI runtime services")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarLeif Lindholm <leif.lindholm@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      0e63ea48
  14. 05 Nov, 2014 4 commits
  15. 03 Oct, 2014 3 commits
    • Laszlo Ersek's avatar
      arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format() · 65ba758f
      Laszlo Ersek authored
      An example log excerpt demonstrating the change:
      
      Before the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data]
      >   0x000040001000-0x00004007ffff [Conventional Memory]
      >   0x000040080000-0x00004072afff [Loader Data]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory]
      >   0x0000964e9000-0x0000964e9fff [Loader Data]
      >   0x0000964ea000-0x000096c52fff [Loader Code]
      >   0x000096c53000-0x00009709dfff [Boot Code]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data]*
      >   0x0000970f5000-0x000097117fff [Runtime Code]*
      >   0x000097118000-0x000097199fff [Runtime Data]*
      >   0x00009719a000-0x0000971dffff [Runtime Code]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory]
      >   0x0000997f9000-0x0000998f1fff [Boot Data]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory]
      >   0x0000999eb000-0x00009af09fff [Boot Data]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory]
      >   0x00009af22000-0x00009af46fff [Boot Data]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory]
      >   0x00009af5c000-0x00009afe1fff [Boot Data]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory]
      >   0x00009afe3000-0x00009c01ffff [Boot Data]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory]
      >   0x00009efc0000-0x00009f14efff [Boot Code]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code]*
      >   0x00009f163000-0x00009f194fff [Runtime Data]*
      >   0x00009f195000-0x00009f197fff [Boot Data]*
      >   0x00009f198000-0x00009f198fff [Runtime Data]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory]
      >   0x00009f1ad000-0x00009f1affff [Boot Data]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O]
      
      After the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      
      The attribute bitmap is now displayed, in decoded form.
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      65ba758f
    • Dave Young's avatar
      arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefi · 6632210f
      Dave Young authored
      In case efi runtime disabled via noefi kernel cmdline
      arm64_enter_virtual_mode should error out.
      
      At the same time move early_memunmap(memmap.map, mapsize) to the
      beginning of the function or it will leak early mem.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      6632210f
    • Dave Young's avatar
      arm64/efi: uefi_init error handling fix · 88f8abd5
      Dave Young authored
      There's one early memmap leak in uefi_init error path, fix it and
      slightly tune the error handling code.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Acked-by: default avatarMark Salter <msalter@redhat.com>
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      88f8abd5
  16. 22 Sep, 2014 2 commits
    • Catalin Marinas's avatar
      Revert "arm64: dmi: Add SMBIOS/DMI support" · 6f325eaa
      Catalin Marinas authored
      This reverts commit 668ebd10.
      
      ... because of lots of warnings during boot if Linux isn't started as an EFI
      application:
      
      WARNING: CPU: 4 PID: 1 at
      /work/Linux/linux-2.6-aarch64/drivers/firmware/dmi_scan.c:591 dmi_matches+0x10c/0x110()
      dmi check: not initialized yet.
      Modules linked in:
      CPU: 4 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc4+ #606
      Call trace:
      [<ffffffc000087fb0>] dump_backtrace+0x0/0x124
      [<ffffffc0000880e4>] show_stack+0x10/0x1c
      [<ffffffc0004d58f8>] dump_stack+0x74/0xb8
      [<ffffffc0000ab640>] warn_slowpath_common+0x8c/0xb4
      [<ffffffc0000ab6b4>] warn_slowpath_fmt+0x4c/0x58
      [<ffffffc0003f2d7c>] dmi_matches+0x108/0x110
      [<ffffffc0003f2da8>] dmi_check_system+0x24/0x68
      [<ffffffc0006974c4>] atkbd_init+0x10/0x34
      [<ffffffc0000814ac>] do_one_initcall+0x88/0x1a0
      [<ffffffc00067aab4>] kernel_init_freeable+0x148/0x1e8
      [<ffffffc0004d2c64>] kernel_init+0x10/0xd4
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6f325eaa
    • Yi Li's avatar
      arm64: dmi: Add SMBIOS/DMI support · 668ebd10
      Yi Li authored
      SMBIOS is important for server hardware vendors. It implements a spec for
      providing descriptive information about the platform. Things like serial
      numbers, physical layout of the ports, build configuration data, and the like.
      
      This has been tested by dmidecode and lshw tools.
      
      This patch adds the call to dmi_scan_machine() to arm64_enter_virtual_mode(),
      as that is the point where the EFI Configuration Tables are registered as
      being available. It needs to be in an early_initcall anyway as dmi_id_init(),
      which is an arch_initcall itself, depends on dmi_scan_machine() having been
      called already.
      Signed-off-by: default avatarYi Li <yi.li@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      668ebd10
  17. 22 Aug, 2014 1 commit
  18. 19 Aug, 2014 1 commit
  19. 18 Jul, 2014 1 commit
  20. 07 Jul, 2014 1 commit
  21. 23 May, 2014 1 commit
  22. 30 Apr, 2014 1 commit