1. 05 4月, 2017 8 次提交
  2. 18 3月, 2017 1 次提交
    • D
      efi/esrt: Cleanup bad memory map log messages · 822f5845
      Daniel Drake 提交于
      The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both
      log 2 error messages during boot:
      
         efi: requested map not found.
         esrt: ESRT header is not in the memory map.
      
      Searching the web, this seems to affect many other platforms too.
      Since these messages are logged as errors, they appear on-screen during
      the boot process even when using the "quiet" boot parameter used by
      distros.
      
      Demote the ESRT error to a warning so that it does not appear on-screen,
      and delete the error logging from efi_mem_desc_lookup; both callsites
      of that function log more specific messages upon failure.
      
      Out of curiosity I looked closer at the Weibu F3C. There is no entry in
      the UEFI-provided memory map which corresponds to the ESRT pointer, but
      hacking the code to map it anyway, the ESRT does appear to be valid with
      2 entries.
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      822f5845
  3. 02 3月, 2017 4 次提交
  4. 07 2月, 2017 3 次提交
  5. 04 2月, 2017 1 次提交
  6. 02 2月, 2017 1 次提交
    • A
      efi/fdt: Avoid FDT manipulation after ExitBootServices() · c8f325a5
      Ard Biesheuvel 提交于
      Some AArch64 UEFI implementations disable the MMU in ExitBootServices(),
      after which unaligned accesses to RAM are no longer supported.
      
      Commit:
      
        abfb7b68 ("efi/libstub/arm*: Pass latest memory map to the kernel")
      
      fixed an issue in the memory map handling of the stub FDT code, but
      inadvertently created an issue with such firmware, by moving some
      of the FDT manipulation to after the invocation of ExitBootServices().
      
      Given that the stub's libfdt implementation uses the ordinary, accelerated
      string functions, which rely on hardware handling of unaligned accesses,
      manipulating the FDT with the MMU off may result in alignment faults.
      
      So fix the situation by moving the update_fdt_memmap() call into the
      callback function invoked by efi_exit_boot_services() right before it
      calls the ExitBootServices() UEFI service (which is arguably a better
      place for it anyway)
      
      Note that disabling the MMU in ExitBootServices() is not compliant with
      the UEFI spec, and carries great risk due to the fact that switching from
      cached to uncached memory accesses halfway through compiler generated code
      (i.e., involving a stack) can never be done in a way that is architecturally
      safe.
      
      Fixes: abfb7b68 ("efi/libstub/arm*: Pass latest memory map to the kernel")
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: NRiku Voipio <riku.voipio@linaro.org>
      Cc: <stable@vger.kernel.org>
      Cc: mark.rutland@arm.com
      Cc: linux-efi@vger.kernel.org
      Cc: matt@codeblueprint.co.uk
      Cc: leif.lindholm@linaro.org
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1485971102-23330-2-git-send-email-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c8f325a5
  7. 01 2月, 2017 6 次提交
  8. 31 1月, 2017 1 次提交
  9. 26 1月, 2017 1 次提交
  10. 17 1月, 2017 2 次提交
  11. 11 1月, 2017 1 次提交
  12. 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
  13. 04 1月, 2017 1 次提交
    • S
      drivers: psci: annotate timer on stack to silence odebug messages · 4309cfe3
      Sudeep Holla 提交于
      When DEBUG_OBJECTS config is enabled, we get the below odebug warnings:
      
      ODEBUG: object is on stack, but not annotated
      
      WARNING: CPU: 3 PID: 1304 at kernel/lib/debugobjects.c:300 __debug_object_init+0x1f0/0x458
      CPU: 3 PID: 1304 Comm: psci_suspend_te Tainted: G W 4.9.0-06564-gf80f3f199260 #284
      task: ffffe9e1b55a1600 task.stack: ffffe9e1b51c0000
      PC is at __debug_object_init+0x1f0/0x458
      LR is at __debug_object_init+0x1ec/0x458
      Call trace:
       __debug_object_init+0x1f0/0x458
       debug_object_activate+0x150/0x260
       mod_timer+0xb4/0x4c0
       suspend_test_thread+0x1cc/0x3c0
       kthread+0x110/0x140
       ret_from_fork+0x10/0x40
      
      This patch annotates the timer on the stack using setup_timer_on_stack
      function to remove the above warnings.
      
      Cc: Kevin Brodsky <kevin.brodsky@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      4309cfe3
  14. 30 12月, 2016 1 次提交
  15. 28 12月, 2016 1 次提交
  16. 19 12月, 2016 1 次提交
  17. 14 12月, 2016 1 次提交
    • P
      Remove references to dead make variable LINUX_INCLUDE · 846221cf
      Paul Bolle 提交于
      Commit 4fd06960 ("Use the new x86 setup code for i386") introduced a
      reference to the make variable LINUX_INCLUDE. That reference got moved
      around a bit and copied twice and now there are three references to it.
      
      There has never been a definition of that variable. (Presumably that is
      because it started out as a mistyped reference to LINUXINCLUDE.) So this
      reference has always been an empty string. Let's remove it before it
      spreads any further.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      846221cf
  18. 26 11月, 2016 2 次提交
    • T
      drivers: psci: Allow PSCI node to be disabled · d09a0011
      Thierry Reding 提交于
      Allow disabling PSCI support (mostly for testing purposes) by setting
      the status property to "disabled". This makes the node behave in much
      the same way as proper device nodes.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      d09a0011
    • K
      drivers: psci: PSCI checker module · ea8b1c4a
      Kevin Brodsky 提交于
      On arm and arm64, PSCI is one of the possible firmware interfaces
      used for power management. This includes both turning CPUs on and off,
      and suspending them (entering idle states).
      
      This patch adds a PSCI checker module that enables basic testing of
      PSCI operations during startup. There are two main tests: CPU
      hotplugging and suspending.
      
      In the hotplug tests, the hotplug API is used to turn off and on again
      all CPUs in the system, and then all CPUs in each cluster, checking
      the consistency of the return codes.
      
      In the suspend tests, a high-priority thread is created on each core
      and uses low-level cpuidle functionalities to enter suspend, in all
      the possible states and multiple times. This should allow a maximum
      number of CPUs to enter the same sleep state at the same or slightly
      different time.
      
      In essence, the suspend tests use a principle similar to that of the
      intel_powerclamp driver (drivers/thermal/intel_powerclamp.c), but the
      threads are only kept for the duration of the test (they are already
      gone when userspace is started) and it does not require to stop/start
      the tick.
      
      While in theory power management PSCI functions (CPU_{ON,OFF,SUSPEND})
      could be directly called, this proved too difficult as it would imply
      the duplication of all the logic used by the kernel to allow for a
      clean shutdown/bringup/suspend of the CPU (the deepest sleep states
      implying potentially the shutdown of the CPU).
      
      Note that this file cannot be compiled as a loadable module, since it
      uses a number of non-exported identifiers (essentially for
      PSCI-specific checks and direct use of cpuidle) and relies on the
      absence of userspace to avoid races when calling hotplug and cpuidle
      functions.
      
      For now at least, CONFIG_PSCI_CHECKER is mutually exclusive with
      CONFIG_TORTURE_TEST, because torture tests may also use hotplug and
      cause false positives in the hotplug tests.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> [torture test config]
      Signed-off-by: NKevin Brodsky <kevin.brodsky@arm.com>
      [lpieralisi: added cpuidle locking, reworded commit log/kconfig entry]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      ea8b1c4a
  19. 25 11月, 2016 1 次提交
    • A
      efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit · 018edcfa
      Ard Biesheuvel 提交于
      The UEFI stub executes in the context of the firmware, which identity
      maps the available system RAM, which implies that only memory below
      4 GB can be used for allocations on 32-bit architectures, even on [L]PAE
      capable hardware.
      
      So ignore any reported memory above 4 GB in efi_random_alloc(). This
      also fixes a reported build problem on ARM under -Os, where the 64-bit
      logical shift relies on a software routine that the ARM decompressor does
      not provide.
      
      A second [minor] issue is also fixed, where the '+ 1' is moved out of
      the shift, where it belongs: the reason for its presence is that a
      memory region where start == end should count as a single slot, given
      that 'end' takes the desired size and alignment of the allocation into
      account.
      
      To clarify the code in this regard, rename start/end to 'first_slot' and
      'last_slot', respectively, and introduce 'region_end' to describe the
      last usable address of the current region.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1480010543-25709-2-git-send-email-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      018edcfa
  20. 24 11月, 2016 2 次提交