1. 14 1月, 2017 1 次提交
    • P
      efi/x86: Prune invalid memory map entries and fix boot regression · 0100a3e6
      Peter Jones 提交于
      Some machines, such as the Lenovo ThinkPad W541 with firmware GNET80WW
      (2.28), include memory map entries with phys_addr=0x0 and num_pages=0.
      
      These machines fail to boot after the following commit,
      
        commit 8e80632f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
      
      Fix this by removing such bogus entries from the memory map.
      
      Furthermore, currently the log output for this case (with efi=debug)
      looks like:
      
       [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |  |  |  |  |  ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
      
      This is clearly wrong, and also not as informative as it could be.  This
      patch changes it so that if we find obviously invalid memory map
      entries, we print an error and skip those entries.  It also detects the
      display of the address range calculation overflow, so the new output is:
      
       [    0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
       [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |   |  |  |  |  ] range=[0x0000000000000000-0x0000000000000000] (invalid)
      
      It also detects memory map sizes that would overflow the physical
      address, for example phys_addr=0xfffffffffffff000 and
      num_pages=0x0200000000000001, and prints:
      
       [    0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
       [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |   |  |  |  |  ] range=[phys_addr=0xfffffffffffff000-0x20ffffffffffffffff] (invalid)
      
      It then removes these entries from the memory map.
      Signed-off-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [ardb: refactor for clarity with no functional changes, avoid PAGE_SHIFT]
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      [Matt: Include bugzilla info in commit log]
      Cc: <stable@vger.kernel.org> # v4.9+
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=191121Signed-off-by: NIngo Molnar <mingo@kernel.org>
      0100a3e6
  2. 07 1月, 2017 1 次提交
    • N
      x86/efi: Don't allocate memmap through memblock after mm_init() · 20b1e22d
      Nicolai Stange 提交于
      With the following commit:
      
        4bc9f92e ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
      
      ...  efi_bgrt_init() calls into the memblock allocator through
      efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() has been called.
      
      Indeed, KASAN reports a bad read access later on in efi_free_boot_services():
      
        BUG: KASAN: use-after-free in efi_free_boot_services+0xae/0x24c
                  at addr ffff88022de12740
        Read of size 4 by task swapper/0/0
        page:ffffea0008b78480 count:0 mapcount:-127
        mapping:          (null) index:0x1 flags: 0x5fff8000000000()
        [...]
        Call Trace:
         dump_stack+0x68/0x9f
         kasan_report_error+0x4c8/0x500
         kasan_report+0x58/0x60
         __asan_load4+0x61/0x80
         efi_free_boot_services+0xae/0x24c
         start_kernel+0x527/0x562
         x86_64_start_reservations+0x24/0x26
         x86_64_start_kernel+0x157/0x17a
         start_cpu+0x5/0x14
      
      The instruction at the given address is the first read from the memmap's
      memory, i.e. the read of md->type in efi_free_boot_services().
      
      Note that the writes earlier in efi_arch_mem_reserve() don't splat because
      they're done through early_memremap()ed addresses.
      
      So, after memblock is gone, allocations should be done through the "normal"
      page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
      it from efi_arch_mem_reserve(), efi_free_boot_services() and, for the sake
      of consistency, from efi_fake_memmap() as well.
      
      Note that for the latter, the memmap allocations cease to be page aligned.
      This isn't needed though.
      Tested-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NNicolai Stange <nicstange@gmail.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org> # v4.9
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Mika Penttilä <mika.penttila@nextfour.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 4bc9f92e ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
      Link: http://lkml.kernel.org/r/20170105125130.2815-1-nicstange@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      20b1e22d
  3. 13 11月, 2016 2 次提交
    • M
      x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y · f6697df3
      Matt Fleming 提交于
      Booting an EFI mixed mode kernel has been crashing since commit:
      
        e37e43a4 ("x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)")
      
      The user-visible effect in my test setup was the kernel being unable
      to find the root file system ramdisk. This was likely caused by silent
      memory or page table corruption.
      
      Enabling CONFIG_DEBUG_VIRTUAL=y immediately flagged the thunking code as
      abusing virt_to_phys() because it was passing addresses that were not
      part of the kernel direct mapping.
      
      Use the slow version instead, which correctly handles all memory
      regions by performing a page table walk.
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112210424.5157-3-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f6697df3
    • B
      x86/efi: Fix EFI memmap pointer size warning · 02e56902
      Borislav Petkov 提交于
      Fix this when building on 32-bit:
      
        arch/x86/platform/efi/efi.c: In function ‘__efi_enter_virtual_mode’:
        arch/x86/platform/efi/efi.c:911:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
             (efi_memory_desc_t *)pa);
             ^
        arch/x86/platform/efi/efi.c:918:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
             (efi_memory_desc_t *)pa);
             ^
      
      The @pa local variable is declared as phys_addr_t and that is a u64 when
      CONFIG_PHYS_ADDR_T_64BIT=y. (The last is enabled on 32-bit on a PAE
      build.)
      
      However, its value comes from __pa() which is basically doing pointer
      arithmetic and checking, and returns unsigned long as it is the native
      pointer width.
      
      So let's use an unsigned long too. It should be fine to do so because
      the later users cast it to a pointer too.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112210424.5157-2-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      02e56902
  4. 21 9月, 2016 1 次提交
  5. 20 9月, 2016 2 次提交
    • M
      x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE · 92dc3350
      Matt Fleming 提交于
      Mike Galbraith reported that his machine started rebooting during boot
      after,
      
        commit 8e80632f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
      
      The ESRT table on his machine is 56 bytes and at no point in the
      efi_arch_mem_reserve() call path is that size rounded up to
      EFI_PAGE_SIZE, nor is the start address on an EFI_PAGE_SIZE boundary.
      
      Since the EFI memory map only deals with whole pages, inserting an EFI
      memory region with 56 bytes results in a new entry covering zero
      pages, and completely screws up the calculations for the old regions
      that were trimmed.
      
      Round all sizes upwards, and start addresses downwards, to the nearest
      EFI_PAGE_SIZE boundary.
      
      Additionally, efi_memmap_insert() expects the mem::range::end value to
      be one less than the end address for the region.
      Reported-by: NMike Galbraith <umgwanakikbuti@gmail.com>
      Reported-by: NMike Krinkin <krinkin.m.u@gmail.com>
      Tested-by: NMike Krinkin <krinkin.m.u@gmail.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      92dc3350
    • M
      x86/efi: Only map RAM into EFI page tables if in mixed-mode · 12976670
      Matt Fleming 提交于
      Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
      multi-terabyte HP machine results in boot crashes, because the EFI
      region mapping functions loop forever while trying to map those
      regions describing RAM.
      
      While this patch doesn't fix the underlying hang, there's really no
      reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
      when mixed-mode is not in use at runtime.
      Reported-by: NWaiman Long <waiman.long@hpe.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Scott J Norton <scott.norton@hpe.com>
      Cc: Douglas Hatch <doug.hatch@hpe.com>
      Cc: <stable@vger.kernel.org> # v4.6+
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      12976670
  6. 09 9月, 2016 9 次提交
    • M
      x86/efi: Use kmalloc_array() in efi_call_phys_prolog() · 20ebc15e
      Markus Elfring 提交于
      * A multiplication for the size determination of a memory allocation
        indicated that an array data structure should be processed.
        Thus reuse the corresponding function "kmalloc_array".
      
        This issue was detected by using the Coccinelle software.
      
      * Replace the specification of a data type by a pointer dereference
        to make the corresponding size determination a bit safer according to
        the Linux coding style convention.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      20ebc15e
    • R
      x86/efi: Defer efi_esrt_init until after memblock_x86_fill · 3dad6f7f
      Ricardo Neri 提交于
      Commit 7b02d53e7852 ("efi: Allow drivers to reserve boot services forever")
      introduced a new efi_mem_reserve to reserve the boot services memory
      regions forever. This reservation involves allocating a new EFI memory
      range descriptor. However, allocation can only succeed if there is memory
      available for the allocation. Otherwise, error such as the following may
      occur:
      
      esrt: Reserving ESRT space from 0x000000003dd6a000 to 0x000000003dd6a010.
      Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0 bytes below \
       0x0.
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc5+ #503
       0000000000000000 ffffffff81e03ce0 ffffffff8131dae8 ffffffff81bb6c50
       ffffffff81e03d70 ffffffff81e03d60 ffffffff8111f4df 0000000000000018
       ffffffff81e03d70 ffffffff81e03d08 00000000000009f0 00000000000009f0
      Call Trace:
       [<ffffffff8131dae8>] dump_stack+0x4d/0x65
       [<ffffffff8111f4df>] panic+0xc5/0x206
       [<ffffffff81f7c6d3>] memblock_alloc_base+0x29/0x2e
       [<ffffffff81f7c6e3>] memblock_alloc+0xb/0xd
       [<ffffffff81f6c86d>] efi_arch_mem_reserve+0xbc/0x134
       [<ffffffff81fa3280>] efi_mem_reserve+0x2c/0x31
       [<ffffffff81fa3280>] ? efi_mem_reserve+0x2c/0x31
       [<ffffffff81fa40d3>] efi_esrt_init+0x19e/0x1b4
       [<ffffffff81f6d2dd>] efi_init+0x398/0x44a
       [<ffffffff81f5c782>] setup_arch+0x415/0xc30
       [<ffffffff81f55af1>] start_kernel+0x5b/0x3ef
       [<ffffffff81f55434>] x86_64_start_reservations+0x2f/0x31
       [<ffffffff81f55520>] x86_64_start_kernel+0xea/0xed
      ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0
           bytes below 0x0.
      
      An inspection of the memblock configuration reveals that there is no memory
      available for the allocation:
      
      MEMBLOCK configuration:
       memory size = 0x0 reserved size = 0x4f339c0
       memory.cnt  = 0x1
       memory[0x0]    [0x00000000000000-0xffffffffffffffff], 0x0 bytes on node 0\
                       flags: 0x0
       reserved.cnt  = 0x4
       reserved[0x0]  [0x0000000008c000-0x0000000008c9bf], 0x9c0 bytes flags: 0x0
       reserved[0x1]  [0x0000000009f000-0x000000000fffff], 0x61000 bytes\
                       flags: 0x0
       reserved[0x2]  [0x00000002800000-0x0000000394bfff], 0x114c000 bytes\
                       flags: 0x0
       reserved[0x3]  [0x000000304e4000-0x00000034269fff], 0x3d86000 bytes\
                       flags: 0x0
      
      This situation can be avoided if we call efi_esrt_init after memblock has
      memory regions for the allocation.
      
      Also, the EFI ESRT driver makes use of early_memremap'pings. Therfore, we
      do not want to defer efi_esrt_init for too long. We must call such function
      while calls to early_memremap are still valid.
      
      A good place to meet the two aforementioned conditions is right after
      memblock_x86_fill, grouped with other EFI-related functions.
      Reported-by: NScott Lawson <scott.lawson@intel.com>
      Signed-off-by: NRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      3dad6f7f
    • A
      x86/efi: Map in physical addresses in efi_map_region_fixed · 0513fe1d
      Alex Thorlton 提交于
      This is a simple change to add in the physical mappings as well as the
      virtual mappings in efi_map_region_fixed.  The motivation here is to
      get access to EFI runtime code that is only available via the 1:1
      mappings on a kexec'd kernel.
      
      The added call is essentially the kexec analog of the first __map_region
      that Boris put in efi_map_region in commit d2f7cbe7 ("x86/efi:
      Runtime services virtual mapping").
      Signed-off-by: NAlex Thorlton <athorlton@sgi.com>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      0513fe1d
    • M
      x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data · 4bc9f92e
      Matt Fleming 提交于
      efi_mem_reserve() allows us to permanently mark EFI boot services
      regions as reserved, which means we no longer need to copy the image
      data out and into a separate buffer.
      
      Leaving the data in the original boot services region has the added
      benefit that BGRT images can now be passed across kexec reboot.
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd 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>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Môshe van der Sterre <me@moshe.nl>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      4bc9f92e
    • M
      efi/runtime-map: Use efi.memmap directly instead of a copy · 31ce8cc6
      Matt Fleming 提交于
      Now that efi.memmap is available all of the time there's no need to
      allocate and build a separate copy of the EFI memory map.
      
      Furthermore, efi.memmap contains boot services regions but only those
      regions that have been reserved via efi_mem_reserve(). Using
      efi.memmap allows us to pass boot services across kexec reboot so that
      the ESRT and BGRT drivers will now work.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd 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: NMatt Fleming <matt@codeblueprint.co.uk>
      31ce8cc6
    • M
      efi: Allow drivers to reserve boot services forever · 816e7612
      Matt Fleming 提交于
      Today, it is not possible for drivers to reserve EFI boot services for
      access after efi_free_boot_services() has been called on x86. For
      ARM/arm64 it can be done simply by calling memblock_reserve().
      
      Having this ability for all three architectures is desirable for a
      couple of reasons,
      
        1) It saves drivers copying data out of those regions
        2) kexec reboot can now make use of things like ESRT
      
      Instead of using the standard memblock_reserve() which is insufficient
      to reserve the region on x86 (see efi_reserve_boot_services()), a new
      API is introduced in this patch; efi_mem_reserve().
      
      efi.memmap now always represents which EFI memory regions are
      available. On x86 the EFI boot services regions that have not been
      reserved via efi_mem_reserve() will be removed from efi.memmap during
      efi_free_boot_services().
      
      This has implications for kexec, since it is not possible for a newly
      kexec'd kernel to access the same boot services regions that the
      initial boot kernel had access to unless they are reserved by every
      kexec kernel in the chain.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd 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: NMatt Fleming <matt@codeblueprint.co.uk>
      816e7612
    • M
      efi: Add efi_memmap_init_late() for permanent EFI memmap · dca0f971
      Matt Fleming 提交于
      Drivers need a way to access the EFI memory map at runtime. ARM and
      arm64 currently provide this by remapping the EFI memory map into the
      vmalloc space before setting up the EFI virtual mappings.
      
      x86 does not provide this functionality which has resulted in the code
      in efi_mem_desc_lookup() where it will manually map individual EFI
      memmap entries if the memmap has already been torn down on x86,
      
        /*
         * If a driver calls this after efi_free_boot_services,
         * ->map will be NULL, and the target may also not be mapped.
         * So just always get our own virtual map on the CPU.
         *
         */
        md = early_memremap(p, sizeof (*md));
      
      There isn't a good reason for not providing a permanent EFI memory map
      for runtime queries, especially since the EFI regions are not mapped
      into the standard kernel page tables.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd 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: NMatt Fleming <matt@codeblueprint.co.uk>
      dca0f971
    • M
      efi: Refactor efi_memmap_init_early() into arch-neutral code · 9479c7ce
      Matt Fleming 提交于
      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: NArd 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: NMatt Fleming <matt@codeblueprint.co.uk>
      9479c7ce
    • M
      x86/efi: Consolidate region mapping logic · ab72a27d
      Matt Fleming 提交于
      EFI regions are currently mapped in two separate places. The bulk of
      the work is done in efi_map_regions() but when CONFIG_EFI_MIXED is
      enabled the additional regions that are required when operating in
      mixed mode are mapping in efi_setup_page_tables().
      
      Pull everything into efi_map_regions() and refactor the test for
      which regions should be mapped into a should_map_region() function.
      Generously sprinkle comments to clarify the different cases.
      Acked-by: NBorislav Petkov <bp@suse.de>
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      ab72a27d
  7. 11 8月, 2016 1 次提交
    • A
      x86/efi: Allocate a trampoline if needed in efi_free_boot_services() · 5bc653b7
      Andy Lutomirski 提交于
      On my Dell XPS 13 9350 with firmware 1.4.4 and SGX on, if I boot
      Fedora 24's grub2-efi off a hard disk, my first 1MB of RAM looks
      like:
      
       efi: mem00: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000000fff] (0MB)
       efi: mem01: [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000001000-0x0000000000027fff] (0MB)
       efi: mem02: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000028000-0x0000000000029fff] (0MB)
       efi: mem03: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002a000-0x000000000002bfff] (0MB)
       efi: mem04: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002c000-0x000000000002cfff] (0MB)
       efi: mem05: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002d000-0x000000000002dfff] (0MB)
       efi: mem06: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002e000-0x0000000000057fff] (0MB)
       efi: mem07: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000058000-0x0000000000058fff] (0MB)
       efi: mem08: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000059000-0x000000000009ffff] (0MB)
      
      My EBDA is at 0x2c000, which blocks off everything from 0x2c000 and
      up, and my trampoline is 0x6000 bytes (6 pages), so it doesn't fit
      in the loader data range at 0x28000.
      
      Without this patch, it panics due to a failure to allocate the
      trampoline.  With this patch, it works:
      
       [  +0.001744] Base memory trampoline at [ffff880000001000] 1000 size 24576
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/998c77b3bf709f3dfed85cb30701ed1a5d8a438b.1470821230.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5bc653b7
  8. 03 8月, 2016 1 次提交
  9. 15 7月, 2016 1 次提交
  10. 14 7月, 2016 1 次提交
    • P
      x86/platform: Audit and remove any unnecessary uses of module.h · cc3ae7b0
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.
      
      One module.h was converted to moduleparam.h since the file had
      multiple module_param() in it, and another file had an instance of
      MODULE_DEVICE_TABLE deleted, since that is a no-op when builtin.
      
      Finally, the 32 bit build coverage of olpc_ofw revealed a couple
      implicit includes, which were pretty self evident to fix based on
      what gcc was complaining about.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-6-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      cc3ae7b0
  11. 27 6月, 2016 2 次提交
  12. 25 6月, 2016 1 次提交
  13. 04 6月, 2016 2 次提交
    • A
      char/genrtc: x86: remove remnants of asm/rtc.h · 463a8630
      Arnd Bergmann 提交于
      Commit 3195ef59 ("x86: Do full rtc synchronization with ntp") had
      the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
      which in turn disables the selection of the CONFIG_RTC and
      CONFIG_GEN_RTC drivers that contain a two older implementations of
      the CONFIG_RTC_DRV_CMOS driver.
      
      This removes x86 from the list for genrtc, and changes all references
      to the asm/rtc.h header to instead point to the interfaces
      from linux/mc146818rtc.h.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      463a8630
    • A
      rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h · 5ab788d7
      Arnd Bergmann 提交于
      Drivers should not really include stuff from asm-generic directly,
      and the PC-style cmos rtc driver does this in order to reuse the
      mc146818 implementation of get_rtc_time/set_rtc_time rather than
      the architecture specific one for the architecture it gets built for.
      
      To make it more obvious what is going on, this moves and renames the
      two functions into include/linux/mc146818rtc.h, which holds the
      other mc146818 specific code. Ideally it would be in a .c file,
      but that would require extra infrastructure as the functions are
      called by multiple drivers with conflicting dependencies.
      
      With this change, the asm-generic/rtc.h header also becomes much
      more generic, so it can be reused more easily across any architecture
      that still relies on the genrtc driver.
      
      The only caller of the internal __get_rtc_time/__set_rtc_time
      functions is in arch/alpha/kernel/rtc.c, and we just change those
      over to the new naming.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      5ab788d7
  14. 17 5月, 2016 1 次提交
    • L
      x86/efi: Fix 7-parameter efi_call()s · 683ad809
      Linus Torvalds 提交于
      Alex Thorlton reported that the SGI/UV code crashes in the efi_call()
      code when invoked with 7 parameters, due to:
      
              mov (%rsp), %rax
              mov 8(%rax), %rax
              ...
              mov %rax, 40(%rsp)
      
      Offset 8 is only true if CONFIG_FRAME_POINTERS is disabled,
      with frame pointers enabled it should be 16.
      
      Furthermore, the SAVE_XMM code saves the old stack pointer, but
      that's just crazy. It saves the stack pointer *AFTER* we've done
      the:
      
              FRAME_BEGIN
      
      ... which will have *changed* the stack pointer, depending on whether
      stack frames are enabled or not.
      
      So when the code then does:
      
              mov (%rsp), %rax
      
      ... we now move that old stack pointer into %rax, but the offset off that
      stack pointer will depend on whether that FRAME_BEGIN saved off %rbp
      or not.
      
      So that whole 8-vs-16 offset confusion depends on the frame pointer!
      If frame pointers were enabled, it will be 16. If they weren't, it
      will be 8.
      
      The right fix is to just get rid of that silly conditional frame
      pointer thing, and always use frame pointers in this stub function.
      And then we don't need that (odd) load to get the old stack
      pointer into %rax - we can just use the frame pointer.
      Reported-by: NAlex Thorlton <athorlton@sgi.com>
      Tested-by: NAlex Thorlton <athorlton@sgi.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/CA%2B55aFzBS2v%3DWnEH83cUDg7XkOremFqJ30BJwF40dCYjReBkUQ@mail.gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      683ad809
  15. 04 5月, 2016 1 次提交
    • J
      x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT · 7f9b474c
      Josh Boyer 提交于
      The promise of pretty boot splashes from firmware via BGRT was at
      best only that; a promise.  The kernel diligently checks to make
      sure the BGRT data firmware gives it is valid, and dutifully warns
      the user when it isn't.  However, it does so via the pr_err log
      level which seems unnecessary.  The user cannot do anything about
      this and there really isn't an error on the part of Linux to
      correct.
      
      This lowers the log level by using pr_notice instead.  Users will
      no longer have their boot process uglified by the kernel reminding
      us that firmware can and often is broken when the 'quiet' kernel
      parameter is specified.  Ironic, considering BGRT is supposed to
      make boot pretty to begin with.
      Signed-off-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Môshe van der Sterre <me@moshe.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1462303781-8686-4-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7f9b474c
  16. 28 4月, 2016 5 次提交
  17. 09 4月, 2016 1 次提交
  18. 12 3月, 2016 1 次提交
    • M
      x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables · 452308de
      Matt Fleming 提交于
      Some machines have EFI regions in page zero (physical address
      0x00000000) and historically that region has been added to the e820
      map via trim_bios_range(), and ultimately mapped into the kernel page
      tables. It was not mapped via efi_map_regions() as one would expect.
      
      Alexis reports that with the new separate EFI page tables some boot
      services regions, such as page zero, are not mapped. This triggers an
      oops during the SetVirtualAddressMap() runtime call.
      
      For the EFI boot services quirk on x86 we need to memblock_reserve()
      boot services regions until after SetVirtualAddressMap(). Doing that
      while respecting the ownership of regions that may have already been
      reserved by the kernel was the motivation behind this commit:
      
        7d68dc3f ("x86, efi: Do not reserve boot services regions within reserved areas")
      
      That patch was merged at a time when the EFI runtime virtual mappings
      were inserted into the kernel page tables as described above, and the
      trick of setting ->numpages (and hence the region size) to zero to
      track regions that should not be freed in efi_free_boot_services()
      meant that we never mapped those regions in efi_map_regions(). Instead
      we were relying solely on the existing kernel mappings.
      
      Now that we have separate page tables we need to make sure the EFI
      boot services regions are mapped correctly, even if someone else has
      already called memblock_reserve(). Instead of stashing a tag in
      ->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
      generally makes no sense to mark a boot services region as required at
      runtime, it's pretty much guaranteed the firmware will not have
      already set this bit.
      
      For the record, the specific circumstances under which Alexis
      triggered this bug was that an EFI runtime driver on his machine was
      responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
      SetVirtualAddressMap().
      
      The event handler for this driver looks like this,
      
        sub rsp,0x28
        lea rdx,[rip+0x2445] # 0xaa948720
        mov ecx,0x4
        call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
        mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
        xor eax,eax
        mov BYTE PTR [r11+0x1],0x1
        add rsp,0x28
        ret
      
      Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
      handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
      instruction because ConvertPointer() was being called to convert the
      address 0x0000000000000000, which when converted is left unchanged and
      remains 0x0000000000000000.
      
      The output of the oops trace gave the impression of a standard NULL
      pointer dereference bug, but because we're accessing physical
      addresses during ConvertPointer(), it wasn't. EFI boot services code
      is stored at that address on Alexis' machine.
      Reported-by: NAlexis Murzeau <amurzeau@gmail.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Raphael Hertzog <hertzog@debian.org>
      Cc: Roger Shimizu <rogershimizu@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125Signed-off-by: NIngo Molnar <mingo@kernel.org>
      452308de
  19. 29 2月, 2016 1 次提交
    • J
      objtool: Mark non-standard object files and directories · c0dd6716
      Josh Poimboeuf 提交于
      Code which runs outside the kernel's normal mode of operation often does
      unusual things which can cause a static analysis tool like objtool to
      emit false positive warnings:
      
       - boot image
       - vdso image
       - relocation
       - realmode
       - efi
       - head
       - purgatory
       - modpost
      
      Set OBJECT_FILES_NON_STANDARD for their related files and directories,
      which will tell objtool to skip checking them.  It's ok to skip them
      because they don't affect runtime stack traces.
      
      Also skip the following code which does the right thing with respect to
      frame pointers, but is too "special" to be validated by a tool:
      
       - entry
       - mcount
      
      Also skip the test_nx module because it modifies its exception handling
      table at runtime, which objtool can't understand.  Fortunately it's
      just a test module so it doesn't matter much.
      
      Currently objtool is the only user of OBJECT_FILES_NON_STANDARD, but it
      might eventually be useful for other tools.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/366c080e3844e8a5b6a0327dc7e8c2b90ca3baeb.1456719558.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c0dd6716
  20. 24 2月, 2016 1 次提交
  21. 22 2月, 2016 3 次提交
    • S
      x86/efi: Only map kernel text for EFI mixed mode · 2ad510dc
      Sai Praneeth 提交于
      The correct symbol to use when figuring out the size of the kernel
      text is '_etext', not '_end' which is the symbol for the entire kernel
      image includes data and debug sections.
      Signed-off-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Cc: Ricardo Neri <ricardo.neri@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1455712566-16727-14-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2ad510dc
    • S
      x86/efi: Map EFI_MEMORY_{XP,RO} memory region bits to EFI page tables · 6d0cc887
      Sai Praneeth 提交于
      Now that we have EFI memory region bits that indicate which regions do
      not need execute permission or read/write permission in the page tables,
      let's use them.
      
      We also check for EFI_NX_PE_DATA and only enforce the restrictive
      mappings if it's present (to allow us to ignore buggy firmware that sets
      bits it didn't mean to and to preserve backwards compatibility).
      
      Instead of assuming that firmware would set appropriate attributes in
      memory descriptor like EFI_MEMORY_RO for code and EFI_MEMORY_XP for
      data, we can expect some firmware out there which might only set *type*
      in memory descriptor to be EFI_RUNTIME_SERVICES_CODE or
      EFI_RUNTIME_SERVICES_DATA leaving away attribute. This will lead to
      improper mappings of EFI runtime regions. In order to avoid it, we check
      attribute and type of memory descriptor to update mappings and moreover
      Windows works this way.
      Signed-off-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Lee, Chun-Yi <jlee@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Cc: Ricardo Neri <ricardo.neri@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1455712566-16727-13-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6d0cc887
    • S
      x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd() · 15f003d2
      Sai Praneeth 提交于
      As part of the preparation for the EFI_MEMORY_RO flag added in the UEFI
      2.5 specification, we need the ability to map pages in kernel page
      tables without _PAGE_RW being set.
      
      Modify kernel_map_pages_in_pgd() to require its callers to pass _PAGE_RW
      if the pages need to be mapped read/write. Otherwise, we'll map the
      pages as read-only.
      Signed-off-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Lee, Chun-Yi <jlee@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Cc: Ricardo Neri <ricardo.neri@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1455712566-16727-12-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      15f003d2
  22. 03 2月, 2016 1 次提交
    • R
      x86/efi: Show actual ending addresses in efi_print_memmap · 1e82b947
      Robert Elliott 提交于
      Adjust efi_print_memmap to print the real end address of each
      range, not 1 byte beyond. This matches other prints like those
      for SRAT and nosave memory.
      
      While investigating grub persistent memory corruption issues, it
      was helpful to make this table match the ending address
      convention used by:
      * the kernel's e820 table prints
      	BIOS-e820: [mem 0x0000001680000000-0x0000001c7fffffff] reserved
      * the kernel's nosave memory prints
      	PM: Registered nosave memory: [mem 0x880000000-0xc7fffffff]
      * the kernel's ACPI System Resource Affinity Table prints
      	SRAT: Node 1 PXM 1 [mem 0x480000000-0x87fffffff]
      * grub's lsmmap and lsefimmap commands
      	reserved  0000001680000000-0000001c7fffffff 00600000     24GiB UC WC WT WB NV
      * the UEFI shell's memmap command
      	Reserved   000000007FC00000-000000007FFFFFFF 0000000000000400 0000000000000001
      
      For example, if you grep all the various logs for c7fffffff, you
      won't find the kernel's line if it uses c80000000.
      
      Also, change the closing ) to ] to match the opening [.
      
      old:
          efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000880000000-0x0000000c80000000) (16384MB)
      
      new:
          efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000880000000-0x0000000c7fffffff] (16384MB)
      Signed-off-by: NRobert Elliott <elliott@hpe.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1454364428-494-12-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1e82b947