1. 19 Mar, 2021 1 commit
  2. 17 Mar, 2021 1 commit
    • Shawn Guo's avatar
      efivars: respect EFI_UNSUPPORTED return from firmware · 483028ed
      Shawn Guo authored
      As per UEFI spec 2.8B section 8.2, EFI_UNSUPPORTED may be returned by
      EFI variable runtime services if no variable storage is supported by
      firmware.  In this case, there is no point for kernel to continue
      efivars initialization.  That said, efivar_init() should fail by
      returning an error code, so that efivarfs will not be mounted on
      /sys/firmware/efi/efivars at all.  Otherwise, user space like efibootmgr
      will be confused by the EFIVARFS_MAGIC seen there, while EFI variable
      calls cannot be made successfully.
      
      Cc: <stable@vger.kernel.org> # v5.10+
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      483028ed
  3. 07 Mar, 2021 1 commit
    • Ard Biesheuvel's avatar
      efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table · 9e9888a0
      Ard Biesheuvel authored
      The EFI_RT_PROPERTIES_TABLE contains a mask of runtime services that are
      available after ExitBootServices(). This mostly does not concern the EFI
      stub at all, given that it runs before that. However, there is one call
      that is made at runtime, which is the call to SetVirtualAddressMap()
      (which is not even callable at boot time to begin with)
      
      So add the missing handling of the RT_PROP table to ensure that we only
      call SetVirtualAddressMap() if it is not being advertised as unsupported
      by the firmware.
      
      Cc: <stable@vger.kernel.org> # v5.10+
      Tested-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      9e9888a0
  4. 06 Mar, 2021 4 commits
  5. 05 Mar, 2021 33 commits