1. 25 2月, 2015 2 次提交
    • I
      firmware: dmi_scan: Fix dmi_len type · 6d9ff473
      Ivan Khoronzhuk 提交于
      According to SMBIOSv3 specification the length of DMI table can be
      up to 32bits wide. So use appropriate type to avoid overflow.
      
      It's obvious that dmi_num theoretically can be more than u16 also,
      so it's can be changed to u32 or at least it's better to use int
      instead of u16, but on that moment I cannot imagine dmi structure
      count more than 65535 and it can require changing type of vars that
      work with it. So I didn't correct it.
      Acked-by: NArd Biesheuvel <ard@linaro.org>
      Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      6d9ff473
    • Y
      efi/libstub: Fix boundary checking in efi_high_alloc() · 7ed620bb
      Yinghai Lu 提交于
      While adding support loading kernel and initrd above 4G to grub2 in legacy
      mode, I was referring to efi_high_alloc().
      That will allocate buffer for kernel and then initrd, and initrd will
      use kernel buffer start as limit.
      
      During testing found two buffers will be overlapped when initrd size is
      very big like 400M.
      
      It turns out efi_high_alloc() boundary checking is not right.
      end - size will be the new start, and should not compare new
      start with max, we need to make sure end is smaller than max.
      
      [ Basically, with the current efi_high_alloc() code it's possible to
        allocate memory above 'max', because efi_high_alloc() doesn't check
        that the tail of the allocation is below 'max'.
      
        If you have an EFI memory map with a single entry that looks like so,
      
         [0xc0000000-0xc0004000]
      
        And want to allocate 0x3000 bytes below 0xc0003000 the current code
        will allocate [0xc0001000-0xc0004000], not [0xc0000000-0xc0003000]
        like you would expect. - Matt ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      7ed620bb
  2. 18 2月, 2015 2 次提交
    • I
      firmware: dmi_scan: Fix dmi scan to handle "End of Table" structure · ce204e9a
      Ivan Khoronzhuk 提交于
      The dmi-sysfs should create "End of Table" entry, that is type 127. But
      after adding initial SMBIOS v3 support fc430262 ("dmi: add support
      for SMBIOS 3.0 64-bit entry point") the 127-0 entry is not handled any
      more, as result it's not created in dmi sysfs for instance. This is
      important because the size of whole DMI table must correspond to sum of
      all DMI entry sizes.
      
      So move the end-of-table check after it's handled by dmi_table.
      Reviewed-by: NArd Biesheuvel <ard@linaro.org>
      Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Cc: <stable@vger.kernel.org> # v3.19
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      ce204e9a
    • M
      Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes" · 43a9f696
      Matt Fleming 提交于
      This reverts commit d1a8d66b.
      
      Ard reported a boot failure when running UEFI under Qemu and Xen and
      experimenting with various Tianocore build options,
      
       "As it turns out, when allocating room for the UEFI memory map using
        UEFI's AllocatePool (), it may result in two new memory map entries
        being created, for instance, when using Tianocore's preallocated region
        feature. For example, the following region
      
        0x00005ead5000-0x00005ebfffff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]
      
        may be split like this
      
        0x00005ead5000-0x00005eae2fff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]
        0x00005eae3000-0x00005eae4fff [Loader Data        |   |  |  |  |  |WB|WT|WC|UC]
        0x00005eae5000-0x00005ebfffff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]
      
        if the preallocated Loader Data region was chosen to be right in the
        middle of the original free space.
      
        After patch d1a8d66b ("efi/libstub: Call get_memory_map() to
        obtain map and desc sizes"), this is not being dealt with correctly
        anymore, as the existing logic to allocate room for a single additional
        entry has become insufficient."
      
      Mark requested to reinstate the old loop we had before commit
      d1a8d66b, which grows the memory map buffer until it's big enough to
      hold the EFI memory map.
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      43a9f696
  3. 14 2月, 2015 2 次提交
    • A
      x86_64: kasan: add interceptors for memset/memmove/memcpy functions · 393f203f
      Andrey Ryabinin 提交于
      Recently instrumentation of builtin functions calls was removed from GCC
      5.0.  To check the memory accessed by such functions, userspace asan
      always uses interceptors for them.
      
      So now we should do this as well.  This patch declares
      memset/memmove/memcpy as weak symbols.  In mm/kasan/kasan.c we have our
      own implementation of those functions which checks memory before accessing
      it.
      
      Default memset/memmove/memcpy now now always have aliases with '__'
      prefix.  For files that built without kasan instrumentation (e.g.
      mm/slub.c) original mem* replaced (via #define) with prefixed variants,
      cause we don't want to check memory accesses there.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      393f203f
    • A
      kasan: add kernel address sanitizer infrastructure · 0b24becc
      Andrey Ryabinin 提交于
      Kernel Address sanitizer (KASan) is a dynamic memory error detector.  It
      provides fast and comprehensive solution for finding use-after-free and
      out-of-bounds bugs.
      
      KASAN uses compile-time instrumentation for checking every memory access,
      therefore GCC > v4.9.2 required.  v4.9.2 almost works, but has issues with
      putting symbol aliases into the wrong section, which breaks kasan
      instrumentation of globals.
      
      This patch only adds infrastructure for kernel address sanitizer.  It's
      not available for use yet.  The idea and some code was borrowed from [1].
      
      Basic idea:
      
      The main idea of KASAN is to use shadow memory to record whether each byte
      of memory is safe to access or not, and use compiler's instrumentation to
      check the shadow memory on each memory access.
      
      Address sanitizer uses 1/8 of the memory addressable in kernel for shadow
      memory and uses direct mapping with a scale and offset to translate a
      memory address to its corresponding shadow address.
      
      Here is function to translate address to corresponding shadow address:
      
           unsigned long kasan_mem_to_shadow(unsigned long addr)
           {
                      return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET;
           }
      
      where KASAN_SHADOW_SCALE_SHIFT = 3.
      
      So for every 8 bytes there is one corresponding byte of shadow memory.
      The following encoding used for each shadow byte: 0 means that all 8 bytes
      of the corresponding memory region are valid for access; k (1 <= k <= 7)
      means that the first k bytes are valid for access, and other (8 - k) bytes
      are not; Any negative value indicates that the entire 8-bytes are
      inaccessible.  Different negative values used to distinguish between
      different kinds of inaccessible memory (redzones, freed memory) (see
      mm/kasan/kasan.h).
      
      To be able to detect accesses to bad memory we need a special compiler.
      Such compiler inserts a specific function calls (__asan_load*(addr),
      __asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16.
      
      These functions check whether memory region is valid to access or not by
      checking corresponding shadow memory.  If access is not valid an error
      printed.
      
      Historical background of the address sanitizer from Dmitry Vyukov:
      
      	"We've developed the set of tools, AddressSanitizer (Asan),
      	ThreadSanitizer and MemorySanitizer, for user space. We actively use
      	them for testing inside of Google (continuous testing, fuzzing,
      	running prod services). To date the tools have found more than 10'000
      	scary bugs in Chromium, Google internal codebase and various
      	open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and
      	lots of others): [2] [3] [4].
      	The tools are part of both gcc and clang compilers.
      
      	We have not yet done massive testing under the Kernel AddressSanitizer
      	(it's kind of chicken and egg problem, you need it to be upstream to
      	start applying it extensively). To date it has found about 50 bugs.
      	Bugs that we've found in upstream kernel are listed in [5].
      	We've also found ~20 bugs in out internal version of the kernel. Also
      	people from Samsung and Oracle have found some.
      
      	[...]
      
      	As others noted, the main feature of AddressSanitizer is its
      	performance due to inline compiler instrumentation and simple linear
      	shadow memory. User-space Asan has ~2x slowdown on computational
      	programs and ~2x memory consumption increase. Taking into account that
      	kernel usually consumes only small fraction of CPU and memory when
      	running real user-space programs, I would expect that kernel Asan will
      	have ~10-30% slowdown and similar memory consumption increase (when we
      	finish all tuning).
      
      	I agree that Asan can well replace kmemcheck. We have plans to start
      	working on Kernel MemorySanitizer that finds uses of unitialized
      	memory. Asan+Msan will provide feature-parity with kmemcheck. As
      	others noted, Asan will unlikely replace debug slab and pagealloc that
      	can be enabled at runtime. Asan uses compiler instrumentation, so even
      	if it is disabled, it still incurs visible overheads.
      
      	Asan technology is easily portable to other architectures. Compiler
      	instrumentation is fully portable. Runtime has some arch-dependent
      	parts like shadow mapping and atomic operation interception. They are
      	relatively easy to port."
      
      Comparison with other debugging features:
      ========================================
      
      KMEMCHECK:
      
        - KASan can do almost everything that kmemcheck can.  KASan uses
          compile-time instrumentation, which makes it significantly faster than
          kmemcheck.  The only advantage of kmemcheck over KASan is detection of
          uninitialized memory reads.
      
          Some brief performance testing showed that kasan could be
          x500-x600 times faster than kmemcheck:
      
      $ netperf -l 30
      		MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET
      		Recv   Send    Send
      		Socket Socket  Message  Elapsed
      		Size   Size    Size     Time     Throughput
      		bytes  bytes   bytes    secs.    10^6bits/sec
      
      no debug:	87380  16384  16384    30.00    41624.72
      
      kasan inline:	87380  16384  16384    30.00    12870.54
      
      kasan outline:	87380  16384  16384    30.00    10586.39
      
      kmemcheck: 	87380  16384  16384    30.03      20.23
      
        - Also kmemcheck couldn't work on several CPUs.  It always sets
          number of CPUs to 1.  KASan doesn't have such limitation.
      
      DEBUG_PAGEALLOC:
      	- KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page
      	  granularity level, so it able to find more bugs.
      
      SLUB_DEBUG (poisoning, redzones):
      	- SLUB_DEBUG has lower overhead than KASan.
      
      	- SLUB_DEBUG in most cases are not able to detect bad reads,
      	  KASan able to detect both reads and writes.
      
      	- In some cases (e.g. redzone overwritten) SLUB_DEBUG detect
      	  bugs only on allocation/freeing of object. KASan catch
      	  bugs right before it will happen, so we always know exact
      	  place of first bad read/write.
      
      [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
      [2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs
      [3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs
      [4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs
      [5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies
      
      Based on work by Andrey Konovalov.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b24becc
  4. 21 1月, 2015 3 次提交
  5. 20 1月, 2015 1 次提交
  6. 16 1月, 2015 1 次提交
    • A
      arm64/efi: efistub: Apply __init annotation · ddeeefe2
      Ard Biesheuvel 提交于
      This ensures all stub component are freed when the kernel proper is
      done booting, by prefixing the names of all ELF sections that have
      the SHF_ALLOC attribute with ".init". This approach ensures that even
      implicitly emitted allocated data (like initializer values and string
      literals) are covered.
      
      At the same time, remove some __init annotations in the stub that have
      now become redundant, and add the __init annotation to handle_kernel_image
      which will now trigger a section mismatch warning without it.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      ddeeefe2
  7. 13 1月, 2015 1 次提交
    • A
      arm64/efi: move SetVirtualAddressMap() to UEFI stub · f3cdfd23
      Ard Biesheuvel 提交于
      In order to support kexec, the kernel needs to be able to deal with the
      state of the UEFI firmware after SetVirtualAddressMap() has been called.
      To avoid having separate code paths for non-kexec and kexec, let's move
      the call to SetVirtualAddressMap() to the stub: this will guarantee us
      that it will only be called once (since the stub is not executed during
      kexec), and ensures that the UEFI state is identical between kexec and
      normal boot.
      
      This implies that the layout of the virtual mapping needs to be created
      by the stub as well. All regions are rounded up to a naturally aligned
      multiple of 64 KB (for compatibility with 64k pages kernels) and recorded
      in the UEFI memory map. The kernel proper reads those values and installs
      the mappings in a dedicated set of page tables that are swapped in during
      UEFI Runtime Services calls.
      Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Acked-by: NMatt Fleming <matt.fleming@intel.com>
      Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      f3cdfd23
  8. 12 1月, 2015 3 次提交
  9. 08 1月, 2015 2 次提交
  10. 20 11月, 2014 1 次提交
  11. 12 11月, 2014 1 次提交
    • A
      efi/x86: Move x86 back to libstub · 243b6754
      Ard Biesheuvel 提交于
      This reverts commit 84be8805, which itself reverted my original
      attempt to move x86 from #include'ing .c files from across the tree
      to using the EFI stub built as a static library.
      
      The issue that affected the original approach was that splitting
      the implementation into several .o files resulted in the variable
      'efi_early' becoming a global with external linkage, which under
      -fPIC implies that references to it must go through the GOT. However,
      dealing with this additional GOT entry turned out to be troublesome
      on some EFI implementations. (GCC's visibility=hidden attribute is
      supposed to lift this requirement, but it turned out not to work on
      the 32-bit build.)
      
      Instead, use a pure getter function to get a reference to efi_early.
      This approach results in no additional GOT entries being generated,
      so there is no need for any changes in the early GOT handling.
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      243b6754
  12. 05 11月, 2014 3 次提交
  13. 20 10月, 2014 1 次提交
  14. 10 10月, 2014 1 次提交
    • Y
      drivers/firmware/memmap.c: don't create memmap sysfs of same firmware_map_entry · 22880ebe
      Yasuaki Ishimatsu 提交于
      By the following commits, we prevented from allocating firmware_map_entry
      of same memory range:
        f0093ede: drivers/firmware/memmap.c: don't allocate firmware_map_entry
                  of same memory range
        49c8b24d: drivers/firmware/memmap.c: pass the correct argument to
                  firmware_map_find_entry_bootmem()
      
      But it's not enough. When PNP0C80 device is added by acpi_scan_init(),
      memmap sysfses of same firmware_map_entry are created twice as follows:
      
        # cat /sys/firmware/memmap/*/start
        0x40000000000
        0x60000000000
        0x4a837000
        0x4a83a000
        0x4a8b5000
        ...
        0x40000000000
        0x60000000000
        ...
      
      The flows of the issues are as follows:
      
        1. e820_reserve_resources() allocates firmware_map_entrys of all
           memory ranges defined in e820. And, these firmware_map_entrys
           are linked with map_entries list.
      
           map_entries -> entry 1 -> ... -> entry N
      
        2. When PNP0C80 device is limited by mem= boot option, acpi_scan_init()
           added the memory device. In this case, firmware_map_add_hotplug()
           allocates firmware_map_entry and creates memmap sysfs.
      
           map_entries -> entry 1 -> ... -> entry N -> entry N+1
                                                       |
                                                       memmap 1
      
        3. firmware_memmap_init() creates memmap sysfses of firmware_map_entrys
           linked with map_entries.
      
           map_entries -> entry 1 -> ... -> entry N -> entry N+1
                           |                 |             |
                           memmap 2          memmap N+1    memmap 1
                                                           memmap N+2
      
      So while hot removing the PNP0C80 device, kernel panic occurs as follows:
      
           BUG: unable to handle kernel paging request at 00000001003e000b
            IP: sysfs_open_file+0x46/0x2b0
            PGD 203a89fe067 PUD 0
            Oops: 0000 [#1] SMP
            ...
            Call Trace:
              do_dentry_open+0x1ef/0x2a0
              finish_open+0x31/0x40
              do_last+0x57c/0x1220
              path_openat+0xc2/0x4c0
              do_filp_open+0x4b/0xb0
              do_sys_open+0xf3/0x1f0
              SyS_open+0x1e/0x20
              system_call_fastpath+0x16/0x1b
      
      The patch adds a check of confirming whether memmap sysfs of
      firmware_map_entry has been created, and does not create memmap
      sysfs of same firmware_map_entry.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      22880ebe
  15. 04 10月, 2014 8 次提交
    • M
      efi: Delete the in_nmi() conditional runtime locking · 60b4dc77
      Matt Fleming 提交于
      commit 5dc3826d9f08 ("efi: Implement mandatory locking for UEFI Runtime
      Services") implemented some conditional locking when accessing variable
      runtime services that Ingo described as "pretty disgusting".
      
      The intention with the !efi_in_nmi() checks was to avoid live-locks when
      trying to write pstore crash data into an EFI variable. Such lockless
      accesses are allowed according to the UEFI specification when we're in a
      "non-recoverable" state, but whether or not things are implemented
      correctly in actual firmware implementations remains an unanswered
      question, and so it would seem sensible to avoid doing any kind of
      unsynchronized variable accesses.
      
      Furthermore, the efi_in_nmi() tests are inadequate because they don't
      account for the case where we call EFI variable services from panic or
      oops callbacks and aren't executing in NMI context. In other words,
      live-locking is still possible.
      
      Let's just remove the conditional locking altogether. Now we've got the
      ->set_variable_nonblocking() EFI variable operation we can abort if the
      runtime lock is already held. Aborting is by far the safest option.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      60b4dc77
    • M
      efi: Provide a non-blocking SetVariable() operation · 6d80dba1
      Matt Fleming 提交于
      There are some circumstances that call for trying to write an EFI
      variable in a non-blocking way. One such scenario is when writing pstore
      data in efi_pstore_write() via the pstore_dump() kdump callback.
      
      Now that we have an EFI runtime spinlock we need a way of aborting if
      there is contention instead of spinning, since when writing pstore data
      from the kdump callback, the runtime lock may already be held by the CPU
      that's running the callback if we crashed in the middle of an EFI
      variable operation.
      
      The situation is sufficiently special that a new EFI variable operation
      is warranted.
      
      Introduce ->set_variable_nonblocking() for this use case. It is an
      optional EFI backend operation, and need only be implemented by those
      backends that usually acquire locks to serialize access to EFI
      variables, as is the case for virt_efi_set_variable() where we now grab
      the EFI runtime spinlock.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      6d80dba1
    • M
      efi: Resolve some shadow warnings · b2fce819
      Mark Rustad 提交于
      It is a really bad idea to declare variables or parameters that
      have the same name as common types. It is valid C, but it gets
      surprising if a macro expansion attempts to declare an inner
      local with that type. Change the local names to eliminate the
      hazard.
      
      Change s16 => str16, s8 => str8.
      
      This resolves warnings seen when using W=2 during make, for instance:
      
      drivers/firmware/efi/vars.c: In function ‘dup_variable_bug’:
      drivers/firmware/efi/vars.c:324:44: warning: declaration of ‘s16’ shadows a global declaration [-Wshadow]
       static void dup_variable_bug(efi_char16_t *s16, efi_guid_t *vendor_guid,
      
      drivers/firmware/efi/vars.c:328:8: warning: declaration of ‘s8’ shadows a global declaration [-Wshadow]
        char *s8;
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b2fce819
    • L
      efi: Introduce efi_md_typeattr_format() · 98d2a6ca
      Laszlo Ersek 提交于
      At the moment, there are three architectures debug-printing the EFI memory
      map at initialization: x86, ia64, and arm64. They all use different format
      strings, plus the EFI memory type and the EFI memory attributes are
      similarly hard to decode for a human reader.
      
      Introduce a helper __init function that formats the memory type and the
      memory attributes in a unified way, to a user-provided character buffer.
      
      The array "memory_type_name" is copied from the arm64 code, temporarily
      duplicating it. The (otherwise optional) braces around each string literal
      in the initializer list are dropped in order to match the kernel coding
      style more closely. The element size is tightened from 32 to 20 bytes
      (maximum actual string length + 1) so that we can derive the field width
      from the element size.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [ Dropped useless 'register' keyword, which compiler will ignore ]
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      98d2a6ca
    • D
      efi: Add kernel param efi=noruntime · 5ae3683c
      Dave Young 提交于
      noefi kernel param means actually disabling efi runtime, Per suggestion
      from Leif Lindholm efi=noruntime should be better. But since noefi is
      already used in X86 thus just adding another param efi=noruntime for
      same purpose.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5ae3683c
    • D
      efi: Move noefi early param code out of x86 arch code · b2e0a54a
      Dave Young 提交于
      noefi param can be used for arches other than X86 later, thus move it
      out of x86 platform code.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b2e0a54a
    • M
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming 提交于
      We need a way to customize the behaviour of the EFI boot stub, in
      particular, we need a way to disable the "chunking" workaround, used
      when reading files from the EFI System Partition.
      
      One of my machines doesn't cope well when reading files in 1MB chunks to
      a buffer above the 4GB mark - it appears that the "chunking" bug
      workaround triggers another firmware bug. This was only discovered with
      commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
      that commit is perfectly valid. The symptom I observed was a corrupt
      initrd rather than any kind of crash.
      
      efi= is now used to specify EFI parameters in two very different
      execution environments, the EFI boot stub and during kernel boot.
      
      There is also a slight performance optimization by enabling efi=nochunk,
      but that's offset by the fact that you're more likely to run into
      firmware issues, at least on x86. This is the rationale behind leaving
      the workaround enabled by default.
      
      Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
      using the current value of 1MB.
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Roy Franz <roy.franz@linaro.org>
      Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5a17dae4
    • A
      efi: Implement mandatory locking for UEFI Runtime Services · 161485e8
      Ard Biesheuvel 提交于
      According to section 7.1 of the UEFI spec, Runtime Services are not fully
      reentrant, and there are particular combinations of calls that need to be
      serialized. Use a spinlock to serialize all Runtime Services with respect
      to all others, even if this is more than strictly needed.
      
      We've managed to get away without requiring a runtime services lock
      until now because most of the interactions with EFI involve EFI
      variables, and those operations are already serialised with
      __efivars->lock.
      
      Some of the assumptions underlying the decision whether locks are
      needed or not (e.g., SetVariable() against ResetSystem()) may not
      apply universally to all [new] architectures that implement UEFI.
      Rather than try to reason our way out of this, let's just implement at
      least what the spec requires in terms of locking.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      161485e8
  16. 24 9月, 2014 1 次提交
    • M
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming 提交于
      This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
      dependencies to <asm/efi.h>") as well as the x86 parts of commit
      f4f75ad5 ("efi: efistub: Convert into static library").
      
      The road leading to these two reverts is long and winding.
      
      The above two commits were merged during the v3.17 merge window and
      turned the common EFI boot stub code into a static library. This
      necessitated making some symbols global in the x86 boot stub which
      introduced new entries into the early boot GOT.
      
      The problem was that we weren't fixing up the newly created GOT entries
      before invoking the EFI boot stub, which sometimes resulted in hangs or
      resets. This failure was reported by Maarten on his Macbook pro.
      
      The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
      boot code paths"). However, that caused issues for Linus when booting
      his Sony Vaio Pro 11. It was subsequently reverted in commit
      f3670394.
      
      So that leaves us back with Maarten's Macbook pro not booting.
      
      At this stage in the release cycle the least risky option is to revert
      the x86 EFI boot stub to the pre-merge window code structure where we
      explicitly #include efi-stub-helper.c instead of linking with the static
      library. The arm64 code remains unaffected.
      
      We can take another swing at the x86 parts for v3.18.
      
      Conflicts:
      	arch/x86/include/asm/efi.h
      Tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
      Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      84be8805
  17. 09 9月, 2014 1 次提交
    • M
      efi/arm64: Fix fdt-related memory reservation · 0ceac9e0
      Mark Salter 提交于
      Commit 86c8b27a:
       "arm64: ignore DT memreserve entries when booting in UEFI mode
      
      prevents early_init_fdt_scan_reserved_mem() from being called for
      arm64 kernels booting via UEFI. This was done because the kernel
      will use the UEFI memory map to determine reserved memory regions.
      That approach has problems in that early_init_fdt_scan_reserved_mem()
      also reserves the FDT itself and any node-specific reserved memory.
      By chance of some kernel configs, the FDT may be overwritten before
      it can be unflattened and the kernel will fail to boot. More subtle
      problems will result if the FDT has node specific reserved memory
      which is not really reserved.
      
      This patch has the UEFI stub remove the memory reserve map entries
      from the FDT as it does with the memory nodes. This allows
      early_init_fdt_scan_reserved_mem() to be called unconditionally
      so that the other needed reservations are made.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      0ceac9e0
  18. 22 8月, 2014 1 次提交
  19. 09 8月, 2014 1 次提交
    • V
      kexec: support kexec/kdump on EFI systems · 6a2c20e7
      Vivek Goyal 提交于
      This patch does two things.  It passes EFI run time mappings to second
      kernel in bootparams efi_info.  Second kernel parse this info and create
      new mappings in second kernel.  That means mappings in first and second
      kernel will be same.  This paves the way to enable EFI in kexec kernel.
      
      This patch also prepares and passes EFI setup data through bootparams.
      This contains bunch of information about various tables and their
      addresses.
      
      These information gathering and passing has been written along the lines
      of what current kexec-tools is doing to make kexec work with UEFI.
      
      [akpm@linux-foundation.org: s/get_efi/efi_get/g, per Matt]
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Matt Fleming <matt@console-pimps.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a2c20e7
  20. 07 8月, 2014 2 次提交
    • Y
      drivers/firmware/memmap.c: don't allocate firmware_map_entry of same memory range · f0093ede
      Yasuaki Ishimatsu 提交于
      When limiting memory by mem= and ACPI DSDT table has PNP0C80,
      firmware_map_entrys of same memory range are allocated and memmap X
      sysfses which have same memory range are created as follows:
      
        # cat /sys/firmware/memmap/0/*
        0x407ffffffff
        0x40000000000
        System RAM
        # cat /sys/firmware/memmap/33/*
        0x407ffffffff
        0x40000000000
        System RAM
        # cat /sys/firmware/memmap/35/*
        0x407ffffffff
        0x40000000000
        System RAM
      
      In this case, when hot-removing memory, kernel panic occurs, showing
      following call trace:
      
        BUG: unable to handle kernel paging request at 00000001003e000b
        IP: sysfs_open_file+0x46/0x2b0
        PGD 203a89fe067 PUD 0
        Oops: 0000 [#1] SMP
        ...
        Call Trace:
          do_dentry_open+0x1ef/0x2a0
          finish_open+0x31/0x40
          do_last+0x57c/0x1220
          path_openat+0xc2/0x4c0
          do_filp_open+0x4b/0xb0
          do_sys_open+0xf3/0x1f0
          SyS_open+0x1e/0x20
          system_call_fastpath+0x16/0x1b
      
      The problem occurs as follows:
      
      When calling e820_reserve_resources(), firmware_map_entrys of all e820
      memory map are allocated.  And all firmware_map_entrys is added
      map_entries list as follows:
      
      map_entries
       -> +--- entry A --------+ -> ...
          | start 0x407ffffffff|
          | end   0x40000000000|
          | type  System RAM   |
          +--------------------+
      
      After that, if ACPI DSDT table has PNP0C80 and the memory range is
      limited by mem=, the PNP0C80 is hot-added.  Then firmware_map_entry of
      PNP0C80 is allocated and added map_entries list as follows:
      
      map_entries
       -> +--- entry A --------+ -> ... -> +--- entry B --------+
          | start 0x407ffffffff|           | start 0x407ffffffff|
          | end   0x40000000000|           | end   0x40000000000|
          | type  System RAM   |           | type  System RAM   |
          +--------------------+           +--------------------+
      
      Then memmap 0 sysfs for entry B is created.
      
      After that, firmware_memmap_init() creates memmap sysfses of all
      firmware_map_entrys in map_entries list.  As a result, memmap 33 sysfs
      for entry A and memmap 35 sysfs for entry B are created.  But kobject of
      entry B has been used by memmap 0 sysfs.  So when creating memmap 35
      sysfs, the kobject is broken.
      
      If hot-removing memory, memmap 0 sysfs is destroyed and kobject of
      memmap 0 sysfs is freed.  But the kobject can be accessed via memmap 35
      sysfs.  So when open memmap 35 sysfs, kernel panic occurs.
      
      This patch checks whether there is firmware_map_entry of same memory
      range in map_entries list and don't allocate firmware_map_entry of same
      memroy range.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f0093ede
    • Y
      drivers/firmware/memmap.c: pass the correct argument to firmware_map_find_entry_bootmem() · 49c8b24d
      Yasuaki Ishimatsu 提交于
      firmware_map_add_hotplug() calls firmware_map_find_entry_bootmem() to
      get free firmware_map_entry.  But end arguments is not correct.  So
      firmware_map_find_entry_bootmem() cannot not find firmware_map_entry.
      
      The patch passes the correct end argument to firmware_map_find_entry_bootmem().
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      49c8b24d
  21. 19 7月, 2014 2 次提交