1. 22 Jul, 2018 4 commits
  2. 17 Jul, 2018 1 commit
    • Ard Biesheuvel's avatar
      efi/esrt: Only call efi_mem_reserve() for boot services memory · 61f0d555
      Ard Biesheuvel authored
      The following commit:
      
        7e1550b8 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")
      
      refactored the implementation of efi_mem_desc_lookup() so that the type
      check is moved to the callers, one of which is the x86 version of
      efi_arch_mem_reserve(), where we added a modified check that only takes
      EFI_BOOT_SERVICES_DATA regions into account.
      
      This is reasonable, since it is the only memory type that requires this,
      but doing so uncovered some unexpected behavior in the ESRT code, which
      permits the ESRT table to reside in other types of memory than what the
      UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
      calls efi_mem_reserve() on the region in question. This may result in
      errors such as
      
        esrt: Reserving ESRT space from 0x000000009c810318 to 0x000000009c810350.
        efi: Failed to lookup EFI memory descriptor for 0x000000009c810318
      
      when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
      to reserve it nonetheless.
      
      So make the call to efi_mem_reserve() conditional on the memory type.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      61f0d555
  3. 15 Jul, 2018 10 commits
    • Ard Biesheuvel's avatar
      fbdev/efifb: Honour UEFI memory map attributes when mapping the FB · 38ac0287
      Ard Biesheuvel authored
      If the framebuffer address provided by the Graphics Output Protocol
      (GOP) is covered by the UEFI memory map, it will tell us which memory
      attributes are permitted when mapping this region. In some cases,
      (KVM guest on ARM), violating this will result in loss of coherency,
      which means that updates sent to the framebuffer by the guest will
      not be observeable by the host, and the emulated display simply does
      not work.
      
      So if the memory map contains such a description, take the attributes
      field into account, and add support for creating WT or WB mappings of
      the framebuffer region.
      Tested-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      38ac0287
    • Ard Biesheuvel's avatar
      efi: Drop type and attribute checks in efi_mem_desc_lookup() · 7e1550b8
      Ard Biesheuvel authored
      The current implementation of efi_mem_desc_lookup() includes the
      following check on the memory descriptor it returns:
      
          if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
              md->type != EFI_BOOT_SERVICES_DATA &&
              md->type != EFI_RUNTIME_SERVICES_DATA) {
                  continue;
          }
      
      This means that only EfiBootServicesData or EfiRuntimeServicesData
      regions are considered, or any other region type provided that it
      has the EFI_MEMORY_RUNTIME attribute set.
      
      Given what the name of the function implies, and the fact that any
      physical address can be described in the UEFI memory map only a single
      time, it does not make sense to impose this condition in the body of the
      loop, but instead, should be imposed by the caller depending on the value
      that is returned to it.
      
      Two such callers exist at the moment:
      
      - The BGRT code when running on x86, via efi_mem_reserve() and
        efi_arch_mem_reserve(). In this case, the region is already known to
        be EfiBootServicesData, and so the check is redundant.
      
      - The ESRT handling code which introduced this function, which calls it
        both directly from efi_esrt_init() and again via efi_mem_reserve() and
        efi_arch_mem_reserve() [on x86].
      
      So let's move this check into the callers instead. This preserves the
      current behavior both for BGRT and ESRT handling, and allows the lookup
      routine to be reused by other [upcoming] users that don't have this
      limitation.
      
      In the ESRT case, keep the entire condition, so that platforms that
      deviate from the UEFI spec and use something other than
      EfiBootServicesData for the ESRT table will keep working as before.
      
      For x86's efi_arch_mem_reserve() implementation, limit the type to
      EfiBootServicesData, since it is the only type the reservation code
      expects to operate on in the first place.
      
      While we're at it, drop the __init annotation so that drivers can use it
      as well.
      Tested-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180711094040.12506-8-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7e1550b8
    • Ard Biesheuvel's avatar
      efi/libstub/arm: Add opt-in Kconfig option for the DTB loader · 3d7ee348
      Ard Biesheuvel authored
      There are various ways a platform can provide a device tree binary
      to the kernel, with different levels of sophistication:
      
      - ideally, the UEFI firmware, which is tightly coupled with the
        platform, provides a device tree image directly as a UEFI
        configuration table, and typically permits the contents to be
        manipulated either via menu options or via UEFI environment
        variables that specify a replacement image,
      
      - GRUB for ARM has a 'devicetree' directive which allows a device
        tree image to be loaded from any location accessible to GRUB, and
        supersede the one provided by the firmware,
      
      - the EFI stub implements a dtb= command line option that allows a
        device tree image to be loaded from a file residing in the same
        file system as the one the kernel image was loaded from.
      
      The dtb= command line option was never intended to be more than a
      development feature, to allow the other options to be implemented
      in parallel. So let's make it an opt-in feature that is disabled
      by default, but can be re-enabled at will.
      
      Note that we already disable the dtb= command line option when we
      detect that we are running with UEFI Secure Boot enabled.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      Acked-by: default avatarLeif 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/20180711094040.12506-7-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3d7ee348
    • Sai Praneeth's avatar
      efi: Remove the declaration of efi_late_init() as the function is unused · f5dcc214
      Sai Praneeth authored
      The following commit:
      
        7b0a9114 ("efi/x86: Move the EFI BGRT init code to early init code")
      
      ... removed the implementation and all the references to
      efi_late_init() but the function is still declared at
      include/linux/efi.h.
      
      Hence, remove the unnecessary declaration.
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@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/20180711094040.12506-6-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f5dcc214
    • Arnd Bergmann's avatar
      efi/cper: Avoid using get_seconds() · 7bb49709
      Arnd Bergmann authored
      get_seconds() is deprecated because of the 32-bit time overflow
      in y2038/y2106 on 32-bit architectures. The way it is used in
      cper_next_record_id() causes an overflow in 2106 when unsigned UTC
      seconds overflow, even on 64-bit architectures.
      
      This starts using ktime_get_real_seconds() to give us more than 32 bits
      of timestamp on all architectures, and then changes the algorithm to use
      39 bits for the timestamp after the y2038 wrap date, plus an always-1
      bit at the top. This gives us another 127 epochs of 136 years, with
      strictly monotonically increasing sequence numbers across boots.
      
      This is almost certainly overkill, but seems better than just extending
      the deadline from 2038 to 2106.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@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/20180711094040.12506-5-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7bb49709
    • Sai Praneeth's avatar
      efi: Use a work queue to invoke EFI Runtime Services · 3eb420e7
      Sai Praneeth authored
      Presently, when a user process requests the kernel to execute any
      UEFI runtime service, the kernel temporarily switches to a separate
      set of page tables that describe the virtual mapping of the UEFI
      runtime services regions in memory. Since UEFI runtime services are
      typically invoked with interrupts enabled, any code that may be called
      during this time, will have an incorrect view of the process's address
      space. Although it is unusual for code running in interrupt context to
      make assumptions about the process context it runs in, there are cases
      (such as the perf subsystem taking samples) where this causes problems.
      
      So let's set up a work queue for calling UEFI runtime services, so that
      the actual calls are made when the work queue items are dispatched by a
      work queue worker running in a separate kernel thread. Such threads are
      not expected to have userland mappings in the first place, and so the
      additional mappings created for the UEFI runtime services can never
      clash with any.
      
      The ResetSystem() runtime service is not covered by the work queue
      handling, since it is not expected to return, and may be called at a
      time when the kernel is torn down to the point where we cannot expect
      work queues to still be operational.
      
      The non-blocking variants of SetVariable() and QueryVariableInfo()
      are also excluded: these are intended to be used from atomic context,
      which obviously rules out waiting for a completion to be signalled by
      another thread. Note that these variants are currently only used for
      UEFI runtime services calls that occur very early in the boot, and
      for ones that occur in critical conditions, e.g., to flush kernel logs
      to UEFI variables via efi-pstore.
      Suggested-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      [ardb: exclude ResetSystem() from the workqueue treatment
             merge from 2 separate patches and rewrite commit log]
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@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/20180711094040.12506-4-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3eb420e7
    • Sai Praneeth's avatar
      efi/x86: Use non-blocking SetVariable() for efi_delete_dummy_variable() · 5a58bc1b
      Sai Praneeth authored
      Presently, efi_delete_dummy_variable() uses set_variable() which might
      block, which the scheduler is rightfully upset about when used from
      the idle thread, producing this splat:
      
        "bad: scheduling from the idle thread!"
      
      So, make efi_delete_dummy_variable() use set_variable_nonblocking(),
      which, as the name suggests, doesn't block.
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@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/20180711094040.12506-3-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5a58bc1b
    • Ingo Molnar's avatar
      efi/x86: Clean up the eboot code · 90a2186b
      Ingo Molnar authored
      Various small cleanups:
      
       - Standardize printk messages:
      
           'alloc' => 'allocate'
           'mem'   => 'memory'
      
         also put variable names in printk messages between quotes.
      
       - Align mass-assignments vertically for better readability
      
       - Break multi-line function prototypes at the name where possible,
         not in the middle of the parameter list
      
       - Use a newline before return statements consistently.
      
       - Use curly braces in a balanced fashion.
      
       - Remove stray newlines.
      
      No change in functionality.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarArd 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/20180711094040.12506-2-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      90a2186b
    • Linus Torvalds's avatar
      Linux 4.18-rc5 · 9d3cce1e
      Linus Torvalds authored
      9d3cce1e
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 41b55d23
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
      
       - A fix for OMAP5 and DRA7 to make the branch predictor hardening
         settings take proper effect on secondary cores
      
       - Disable USB OTG on am3517 since current driver isn't working
      
       - Fix thermal sensor register settings on Armada 38x
      
       - Fix suspend/resume IRQs on pxa3xx
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: dts: am3517.dtsi:  Disable reference to OMAP3 OTG controller
        ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
        ARM: pxa: irq: fix handling of ICMR registers in suspend/resume
        ARM: dts: armada-38x: use the new thermal binding
      41b55d23
  4. 14 Jul, 2018 19 commits
  5. 13 Jul, 2018 6 commits