1. 28 4月, 2016 2 次提交
  2. 03 2月, 2016 3 次提交
  3. 14 1月, 2016 1 次提交
  4. 14 12月, 2015 1 次提交
    • S
      x86/efi-bgrt: Fix kernel panic when mapping BGRT data · 50a0cb56
      Sai Praneeth 提交于
      Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page
      table structures") efi regions have a separate page directory called
      "efi_pgd". In order to access any efi region we have to first shift %cr3
      to this page table. In the bgrt code we are trying to copy bgrt_header
      and image, but these regions fall under "EFI_BOOT_SERVICES_DATA"
      and to access these regions we have to shift %cr3 to efi_pgd and not
      doing so will cause page fault as shown below.
      
      [    0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
      [    0.259126] Freeing SMP alternatives memory: 32K (ffffffff8230e000 - ffffffff82316000)
      [    0.271803] BUG: unable to handle kernel paging request at fffffffefce35002
      [    0.279740] IP: [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
      [    0.286383] PGD 300f067 PUD 0
      [    0.289879] Oops: 0000 [#1] SMP
      [    0.293566] Modules linked in:
      [    0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1-eywa-eywa-built-in-47041+ #2
      [    0.306619] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.1511110114 11/11/2015
      [    0.320925] task: ffffffff820134c0 ti: ffffffff82000000 task.ti: ffffffff82000000
      [    0.329420] RIP: 0010:[<ffffffff821bca49>]  [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
      [    0.338821] RSP: 0000:ffffffff82003f18  EFLAGS: 00010246
      [    0.344852] RAX: fffffffefce35000 RBX: fffffffefce35000 RCX: fffffffefce2b000
      [    0.352952] RDX: 000000008a82b000 RSI: ffffffff8235bb80 RDI: 000000008a835000
      [    0.361050] RBP: ffffffff82003f30 R08: 000000008a865000 R09: ffffffffff202850
      [    0.369149] R10: ffffffff811ad62f R11: 0000000000000000 R12: 0000000000000000
      [    0.377248] R13: ffff88016dbaea40 R14: ffffffff822622c0 R15: ffffffff82003fb0
      [    0.385348] FS:  0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000
      [    0.394533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    0.401054] CR2: fffffffefce35002 CR3: 000000000300c000 CR4: 00000000003406f0
      [    0.409153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    0.417252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [    0.425350] Stack:
      [    0.427638]  ffffffffffffffff ffffffff82256900 ffff88016dbaea40 ffffffff82003f40
      [    0.436086]  ffffffff821bbce0 ffffffff82003f88 ffffffff8219c0c2 0000000000000000
      [    0.444533]  ffffffff8219ba4a ffffffff822622c0 0000000000083000 00000000ffffffff
      [    0.452978] Call Trace:
      [    0.455763]  [<ffffffff821bbce0>] efi_late_init+0x9/0xb
      [    0.461697]  [<ffffffff8219c0c2>] start_kernel+0x463/0x47f
      [    0.467928]  [<ffffffff8219ba4a>] ? set_init_arg+0x55/0x55
      [    0.474159]  [<ffffffff8219b120>] ? early_idt_handler_array+0x120/0x120
      [    0.481669]  [<ffffffff8219b5ee>] x86_64_start_reservations+0x2a/0x2c
      [    0.488982]  [<ffffffff8219b72d>] x86_64_start_kernel+0x13d/0x14c
      [    0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89 c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4 <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$
      [    0.518151] RIP  [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
      [    0.524888]  RSP <ffffffff82003f18>
      [    0.528851] CR2: fffffffefce35002
      [    0.532615] ---[ end trace 7b06521e6ebf2aea ]---
      [    0.537852] Kernel panic - not syncing: Attempted to kill the idle task!
      
      As said above one way to fix this bug is to shift %cr3 to efi_pgd but we
      are not doing that way because it leaks inner details of how we switch
      to EFI page tables into a new call site and it also adds duplicate code.
      Instead, we remove the call to efi_lookup_mapped_addr() and always
      perform early_mem*() instead of early_io*() because we want to remap RAM
      regions and not I/O regions. We also delete efi_lookup_mapped_addr()
      because we are no longer using it.
      Signed-off-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Reported-by: NWendy Wang <wendy.wang@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Ricardo Neri <ricardo.neri@intel.com>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      50a0cb56
  5. 10 12月, 2015 1 次提交
  6. 28 10月, 2015 1 次提交
    • A
      efi: Use correct type for struct efi_memory_map::phys_map · 44511fb9
      Ard Biesheuvel 提交于
      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: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NMatt 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: NIngo Molnar <mingo@kernel.org>
      44511fb9
  7. 12 10月, 2015 5 次提交
  8. 11 10月, 2015 1 次提交
    • M
      efi: Use the generic efi.memmap instead of 'memmap' · 0ce423b6
      Matt Fleming 提交于
      Guenter reports that commit:
      
        7bf79311 ("efi, x86: Rearrange efi_mem_attributes()")
      
      breaks the IA64 compilation with the following error:
      
        drivers/built-in.o: In function `efi_mem_attributes': (.text+0xde962): undefined reference to `memmap'
      
      Instead of using the (rather poorly named) global variable
      'memmap' which doesn't exist on IA64, use efi.memmap which
      points to the 'memmap' object on x86 and arm64 and which is NULL
      for IA64.
      
      The fact that efi.memmap is NULL for IA64 is OK because IA64
      provides its own implementation of efi_mem_attributes().
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Jonathan Zhang <zjzhang@codeaurora.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@gmail.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Link: http://lkml.kernel.org/r/20151003222607.GA2682@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0ce423b6
  9. 08 8月, 2015 2 次提交
  10. 31 7月, 2015 1 次提交
    • R
      efi: Check for NULL efi kernel parameters · 9115c758
      Ricardo Neri 提交于
      Even though it is documented how to specifiy efi parameters, it is
      possible to cause a kernel panic due to a dereference of a NULL pointer when
      parsing such parameters if "efi" alone is given:
      
      PANIC: early exception 0e rip 10:ffffffff812fb361 error 0 cr2 0
      [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc1+ #450
      [ 0.000000]  ffffffff81fe20a9 ffffffff81e03d50 ffffffff8184bb0f 00000000000003f8
      [ 0.000000]  0000000000000000 ffffffff81e03e08 ffffffff81f371a1 64656c62616e6520
      [ 0.000000]  0000000000000069 000000000000005f 0000000000000000 0000000000000000
      [ 0.000000] Call Trace:
      [ 0.000000]  [<ffffffff8184bb0f>] dump_stack+0x45/0x57
      [ 0.000000]  [<ffffffff81f371a1>] early_idt_handler_common+0x81/0xae
      [ 0.000000]  [<ffffffff812fb361>] ? parse_option_str+0x11/0x90
      [ 0.000000]  [<ffffffff81f4dd69>] arch_parse_efi_cmdline+0x15/0x42
      [ 0.000000]  [<ffffffff81f376e1>] do_early_param+0x50/0x8a
      [ 0.000000]  [<ffffffff8106b1b3>] parse_args+0x1e3/0x400
      [ 0.000000]  [<ffffffff81f37a43>] parse_early_options+0x24/0x28
      [ 0.000000]  [<ffffffff81f37691>] ? loglevel+0x31/0x31
      [ 0.000000]  [<ffffffff81f37a78>] parse_early_param+0x31/0x3d
      [ 0.000000]  [<ffffffff81f3ae98>] setup_arch+0x2de/0xc08
      [ 0.000000]  [<ffffffff8109629a>] ? vprintk_default+0x1a/0x20
      [ 0.000000]  [<ffffffff81f37b20>] start_kernel+0x90/0x423
      [ 0.000000]  [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
      [ 0.000000]  [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
      [ 0.000000] RIP 0xffffffff81ba2efc
      
      This panic is not reproducible with "efi=" as this will result in a non-NULL
      zero-length string.
      
      Thus, verify that the pointer to the parameter string is not NULL. This is
      consistent with other parameter-parsing functions which check for NULL pointers.
      Signed-off-by: NRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      9115c758
  11. 01 7月, 2015 1 次提交
  12. 06 5月, 2015 1 次提交
  13. 01 5月, 2015 1 次提交
  14. 21 1月, 2015 2 次提交
  15. 12 1月, 2015 2 次提交
  16. 08 1月, 2015 1 次提交
  17. 05 11月, 2014 1 次提交
  18. 04 10月, 2014 3 次提交
  19. 19 7月, 2014 3 次提交
    • L
      efi: Autoload efivars · 28d54022
      Lee, Chun-Yi 提交于
      The original patch is from Ben Hutchings's contribution to debian
      kernel. Got Ben's permission to remove the code of efi-pstore.c and
      send to linux-efi:
      https://github.com/BlankOn/linux-debian/blob/master/debian/patches/features/all/efi-autoload-efivars.patch
      
      efivars is generally useful to have on EFI systems, and in some cases
      it may be impossible to load it after a kernel upgrade in order to
      complete a boot loader update. At the same time we don't want to waste
      memory on non-EFI systems by making them built-in.
      
      Instead, give them module aliases as if they are platform drivers, and
      register a corresponding platform device whenever EFI runtime services
      are available.  This should trigger udev to load them.
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      28d54022
    • D
      efi: Introduce EFI_PARAVIRT flag · 9f27bc54
      Daniel Kiper 提交于
      Introduce EFI_PARAVIRT flag. If it is set then kernel runs
      on EFI platform but it has not direct control on EFI stuff
      like EFI runtime, tables, structures, etc. If not this means
      that Linux Kernel has direct access to EFI infrastructure
      and everything runs as usual.
      
      This functionality is used in Xen dom0 because hypervisor
      has full control on EFI stuff and all calls from dom0 to
      EFI must be requested via special hypercall which in turn
      executes relevant EFI code in behalf of dom0.
      Signed-off-by: NDaniel Kiper <daniel.kiper@oracle.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      9f27bc54
    • D
      efi: Use early_mem*() instead of early_io*() · abc93f8e
      Daniel Kiper 提交于
      Use early_mem*() instead of early_io*() because all mapped EFI regions
      are memory (usually RAM but they could also be ROM, EPROM, EEPROM, flash,
      etc.) not I/O regions. Additionally, I/O family calls do not work correctly
      under Xen in our case. early_ioremap() skips the PFN to MFN conversion
      when building the PTE. Using it for memory will attempt to map the wrong
      machine frame. However, all artificial EFI structures created under Xen
      live in dom0 memory and should be mapped/unmapped using early_mem*() family
      calls which map domain memory.
      Signed-off-by: NDaniel Kiper <daniel.kiper@oracle.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Mark Salter <msalter@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      abc93f8e
  20. 10 7月, 2014 1 次提交
  21. 19 6月, 2014 1 次提交
    • C
      efi: Fix compiler warnings (unused, const, type) · 6fb8cc82
      Catalin Marinas 提交于
      This patch fixes a few compiler warning in the efi code for unused
      variable, discarding const qualifier and wrong pointer type:
      
      drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’ [-Wunused-variable]
      drivers/firmware/efi/efi.c|368 col 3| warning: passing argument 3 of ‘of_get_flat_dt_prop’ from incompatible pointer type [enabled by default]
      drivers/firmware/efi/efi.c|368 col 8| warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      6fb8cc82
  22. 01 5月, 2014 1 次提交
  23. 05 3月, 2014 2 次提交
  24. 21 12月, 2013 2 次提交