Tag: UEFI

Marvel Universe version of UEFI :-)

~ hucktech ~ Leave a comment

Marvel’s Agents of S.H.I.E.L.D. apparently has another form of UEFI:

“This is called a Unified Extensible Firmware Interface.”

Video clip:

Transcript:

AMD’s IVRS ACPI table

~ hucktech ~ Leave a comment

I just noticed this March-era update to the UEFI list of ACPI specs. It is a large, well-written spec, compared to some of the recent ACPI specs I’ve looked at.

I/O Virtualization Reporting Structure (IVRS)

This document describes AMD I/O Virtualization Technology. AMD I/O Virtualization Technology is embodied in the system-level function called the I/O Memory Management Unit (IOMMU). This document provides the IOMMU behavioral definition and associated design notes. It is intended for the use of system designers, chipset designers, and programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, operating system kernel modules, and virtual machine monitor (VMM) software. The intended user should have prior experience in personal computer design, microprocessor programming, and legacy x86 and AMD64 microprocessor architecture.

Click to access 48882_IOMMU.pdf

http://uefi.org/acpi

UEFI != DRM?

~ hucktech ~ 1 Comment

<soapbox>

https://twitter.com/Intel_UEFI/status/732295351672012800

 

LOL. 🙂

This argument is still happening because while UEFI may not explicitly be a mechanism of DRM, a UEFI vendor can use UEFI as a form of UEFI. Rubber hoses were designed for spraying water, but they are also used as a weapon. OS vendors who are also OEMs can use UEFI to bind their HW to their OS, something that could not be done with an earlier BIOS-based firmware, due to the additional security. UEFI’s Secure Boot security can be used to protect the manufacturer’s interests, or the  owner-user’s interests, and those are not the same. 😦

I think there should be 2 classes of systems, one which the owner can control (General Purpose Computing), and one which the manufacturer controls (Secure Specialized Systems). The latter systems can be used in banks and a subset of embedded systems. Citizen-consumers should be able to purchase a system that they can control. The NIST secure BIOS guidelines permit owners to control their own systems locally, but Secure Boot implementations often do not permit owners that same control.  Don’t let fear of malware let manufacturers develop systems you cannot control.

</soapbox>

fwexpl – PC Firmware Exploitation Tool and Library

~ hucktech ~ Leave a comment

Dmytro Oleksiuk (aka Cr4sh) has a VERY INTERESTING new firmware tool for Windows

PC firmware exploitation tool and library

Project includes the following components:
 * libfwexpl — Hardware abstraction library for Windows (see include/libfwexpl.h).
 * libdsebypass — Windows x64 DSE bypass exploit based on Secret Net 7.4 0day privileges escalation vulnerability (see include/libdsebypass.h).
 * driver — Kernel mode part of libfwexpl.
 * application — Application that implements System Management Mode code execution exploit for 1day vulnerability in SystemSmmAhciAspiLegacyRt UEFI SMM driver of Lenovo firmware.

Options:
  –target <N> — Select known target where <N> is a target number. If –target and –target-addr options are not specified — exploit will use heuristics to find EFI_BOOT_SERVICES structure address that neccessary for SystemSmmAhciAspiLegacyRt driver vulnerability exploitation.
  –target-list — Print all known targets information.
  –target-addr – Use manual address of EFI_BOOT_SERVICES.LocateProtocol field for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified.
  –target-smi – Use manual SMI handler number for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified. If –target-addr was specified without –target-smi — SystemSmmAhciAspiLegacyRt exploit will check all of the possible SMI handlers from 0 to 255.
  –smram-dump — Determinate current SMRAM address and dump it’s contents to file specified by –file option.
  –phys-mem-dump — Full raw physical memory dump into the file specified by –file option.
  –phys-mem-read <addr> — Read physical memory starting from specified address.
  –phys-mem-write <addr> — Write physical memory starting from specified address.
  –length <bytes> — Number of bytes to read or write for –phys-mem-read and –phys-mem-write.  
  –file <path> — Memory dump path to read or write, in case of –phys-mem-read this parameter is optional and when it’s not specified — application will print a hex dump of physical memory to stdout. In case of –smram-dump this parameter is mandatory.
  –exec <addr> — Execute SMM code at specified physical memory address.
  –dse-bypass — Install and exploit Secret Net 7.4 driver to bypass Windows x64 DSE.  
  –test — Run some basic libfwexpl tests.

To learn more about this project please read his blog post, “Exploiting SMM callout vulnerabilities in Lenovo firmware”:
http://blog.cr4.sh/2016/02/exploiting-smm-callout-vulnerabilities.html

https://github.com/Cr4sh/fwexpl

UFS Erase Block command added to UEFI

~ hucktech ~ Leave a comment

Hao Wu of Intel added Erase Block support to UFS (Universal Flash Storage) devices. Since UFS uses SCSI model in UEFI, the SCSI Unmap command was also added, but SCSI Unmap is not fully-implemented for SCSI devices, only for UFS Erase Block support.

[PATCH 0/2] Add Erase Block Protocol support for UFS devices

This patch series add the Erase Block Protocol implementation for UFS devices. Since the UFS transport layer follows the SCSI architecture, therefore, the implementation is added in the ScsiDiskDxe driver.

MdePkg IndustryStandard/Scsi.h: Add Unmap command support
MdeModulePkg ScsiDiskDxe: Add Erase Block Protocol support for UFS devices

For more information, see the patch on the EDK2-devel list, see the UFS 2.0 spec (including section 11.3.9.2). Hmm, unless I’m misreading things, the UFS spec is for members only, not public. 😦

https://lists.01.org/mailman/listinfo/edk2-devel
http://news.gmane.org/gmane.comp.bios.edk2.devel
http://search.gmane.org/search.php?group=gmane.comp.bios.edk2.devel&query=UFS
https://en.wikipedia.org/wiki/Universal_Flash_Storage

Universal Flash Storage (UFS) support added to UEFI

UEFI Secure Boot exploit for Windows Surface??

~ hucktech ~ Leave a comment

A kind reader of this blog pointed this out to me:

It appears that Longhorn has a UEFI exploit, related to Windows surface devices. I’m not sure yet if it requires ARM or Intel system, and I don’t know the details of the exploit, it appears that it has not been released.

https://twitter.com/never_released/status/723144680507117568
https://twitter.com/never_released/status/723146681940738055
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725034729599307777
https://twitter.com/never_released/status/724984950584446976
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/723896207475675136
https://twitter.com/never_released/status/723796480281182208

SuSE adds BIOS/UEFI to their certification bulletins

~ hucktech ~ Leave a comment

Drew of SuSE has a new blog post clarifying UEFI -vs- BIOS:

SuSE even has a certification program, as this blog mentions:

“[…] All YES CERTIFICATION bulletins list how the hardware and operating system were configured and tested during certification. On a bulletin, under the tested configuration section there is a BIOS/UEFI line, it will list either UEFI, BIOS or UEFI-Legacy. This indicates how the system was configured and tested. It then lists the version and date of the system firmware installed on the hardware. […]”

This certification program doesn’t cover [implementation differences in] UEFI Secure Boot. While the current change in their certification — to clarify if system has a UEFI class 1-3 firmware — is nice, what would be USEFUL would be to list CHIPSEC version and a list a list of which security modules it fails. And the results of FWTS’s tests (does Canonical’s FWTS build on SuSE?). When a system is tested, I’d like to see the test results, please. And does this mean that SuSE will not ship any coreboot- or U-Boot-based systems, but always UEFI/BIOS-based ones? Given how crucial firmware is to a system, I am amazed at how little consumers care about this information. I guess I should be happy SuSE is giving 1-line of data to firmware. I’d like a paragraph.

 

https://www.suse.com/communities/blog/comparison-uefi-bios-operating-system-perspective/

UEFI boot support for locked SEDs updated

~ hucktech ~ Leave a comment

Eric Dong of Intel has updated UEFI’s TCG OVAL support, used with SEDs, how the UEFI-based system will work with the locked SEDs, when the user has no valid password:

[Patch] SecurityPkg OpalPasswordDxe: Enhance input password process.

Enhance the input password process, when device in unlock status and user press ESC, shutdown the device. If user reach the max try number, shutdown the device.

+  L”Confirm: Not unlock device and continue boot?.”,
+  L”Press ENTER to confirm, Press Esc to input password”,
+  L”Warning: system in unkown status, must shutdown!”,
+  L”Press ENTER to shutdown.”,

– L”Opal password retry count is expired. Keep lock and continue boot.”,
+ L”Opal password retry count exceeds the limit. Must shutdown!”,
  L”Press ENTER to continue”,

For more information, see the patch on the edk2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

Linux UEFI updates for Linux 4.7

~ hucktech ~ Leave a comment

Matt Fleming has submitted some UEFI updates for Linux. Excerpted/edited announcement:

Folks, this is the second pull request containing v4.7 material. The commits are listed in priority order, with the first patch fixing an oops in the EFI capsule code sitting in tip/efi/core, and the rest being a compiler warning fix, static checker fix, and a couple of cleanups.

* efivarfs: Make efivarfs_file_ioctl static (2016-05-05 16:52:19 +0100)
* Fix an oops in the EFI capsule code reported by the 0day bot because efi_capsule_pending() was grabbing a mutex in the emergency reboot path
* Fix a compiler warning about excessive stack usage in the new efibc driver by kmalloc’ing the efivar_entry object
 * It’s potentially unsafe to pass the address of a pointer to the firmware in efi_capsule_supported(). Instead we can skip the dynamic allocation entirely and put the capsule object on the stack
* Simplify the locking in the efivars code by merging two of efivar_init()’s parameters into one
* Cleanup efivarfs_file_ioctl by marking it as static since it has no external users
* efibc: Fix excessive stack footprint warning
* efi: Merge boolean flag arguments
* efi/capsule: Make efi_capsule_pending() lockless
* efi/capsule: Move ‘capsule’ to the stack in efi_capsule_supported()
* efivarfs: Make efivarfs_file_ioctl static

For more information, see the message on the linux-efi mailing list archives:
http://vger.kernel.org/majordomo-info.html
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next

The UEFI Forum has a security advisory mechanism. They released 2 PDFs, each with a handful of advisories in the EDK2 codebase, back in 2015. There haven’t been any updates since 2015. If you want more recent updates on EDK2 source code, at least for the Linux codepath, watching these linux-efi updates is probably the most transparent way for non-members of the UEFI Forum. If you are a member of the UEFI Forum, I presume they have private forums and issue tracking systems to track non-public advisories. You can also watch the EDK2 commits for security patches, like any open source project.

EDK2 fork for LLVM security analysis

~ hucktech ~ Leave a comment

Steven Shi of Intel\SSG\STO\UEFI Firmware has created an LLVM Clang-centric fork of the EDK2 project. The EDK2 project already supports LLVM clang alongside GCC and ICC and MCS, but this fork appears to be taking advantage of some of LLVM’s security features, like Clang’s Static Analyzer, “special checkers for edk2 security” sounds interesting!

Hello,
I forked a edk2 branch to apply the LLVM compiler and tool chain technologies (http://www.llvm.org/) on the edk2 codebase in below link. If you are also interested in the LLVM/Clang support, please take a look. I welcome and appreciate any feedback or contribution to this branch.

https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm

So far, this branch focus on below items:
* Clang compiler optimization for edk2 code size improvement, e.g. Link Time Optimization (LTO)
* Clang Static Analyzer (scan-build) for edk2, e.g. special checkers for edk2 security, checkers for Intel Firmware Engine automation

There are 4 new tool chains are introduced in branch llvm:
* CLANG38: Clang3.8.0 build tool chain, and enable code size optimization flag (-Os) by default on both Ia32 and X64.
* CLANGLTO38: Base on CLANG38 to enable LLVM Link Time Optimization (LTO) for more aggressive code size improvement.
* CLANGSCAN38: Base on CLANG38 to seamlessly integrate Clang scan-build analyzer infrastructure into edk2 build infrastructure.
* GCCLTO53: Enabled GCC Link Time Optimization (LTO) and code size optimization (-Os) for more aggressive code size improvement.

There are several known issues as below. WELCOME and APPRECIATE any suggestion to them:
* Not use gold linker for now, but directly use standard ld. GNU gold linker ld-new (GNU Binutils 2.26.20160125) 1.11 fails to link edk2 static library file (*.dll) with error message: “ld: internal error in do_layout, at ../../binutils-2.26/gold/object.cc:1819” Have submitted a bug in Bug 20062 – Gold2.26 fail to link Uefi firmware with internal error in do_layout, but ld works (https://sourceware.org/bugzilla/show_bug.cgi?id=20062)
* CLANG LTO optimization (on ld, not on gold) can generate incorrect code. Current CLANGLTO38 LTO X64 debug build will generate wrong code for BasePrintLib.inf and LzmaCustomDecompressLib.inf modules, and the Ovmf boot will hang in these two modules. Already add work around to disable the lto optimization in these two modules’ inf files. Please see the log of commit 6a55aa9c3fa58f275041bf8cda138643f04baf5c
* GCC LTO optimization can generate incorrect code. Current GCCLTO53 is even worse than CLANGLTO38, and there are more modules need to disable the LTO optimization to work around the CPU exceptions during boot time.

For more info, see the patch on the edk2-devel list:
https://github.com/shijunjing/edk2
https://github.com/shijunjing/edk2/tree/llvm
https://lists.01.org/mailman/listinfo/edk2-devel

I wonder if this project is related to the Intel LLVM KLEE/S2E static analysis project that they are hopefully going to open source this year?

Intel firmware security research at WOOT

I hope they take the handful of metrics that William’s LangToolUEFIZBIOS(sp) — his grad project — did. It’ll be a lot simpler as a LLVM filter, no need for all the Java ANTLR code!

Two UEFI Form tools, plus one UEFI C Module complexity tool

ASUS brick warning for Windows updates

~ hucktech ~ Leave a comment

Some ASUS users are having UEFI-related Windows update problems that may brick their systems. A few news sites have stories on this:

[…] KB3133977, a security update for Windows 7, has been identified as the cause for this problem. Following its installation, it forces Windows 7 to enable Secure Boot, even though it is actually not supported by Microsoft anymore. This eventually prevents the system from properly rebooting. Microsoft has clearly stated that it is in no way responsible for this predicament. Providing clarification, a company spokesperson stated that the problem occurs because of how Asus has created some of its motherboards with its own modified version of the Secure Boot feature. In other words, users facing problems in this regard will have to contact Asus directly to have the issue addressed. […]

http://tech.firstpost.com/news-analysis/a-microsoft-windows-7-update-is-bricking-some-pcs-with-asus-motherboards-313729.html
http://www.thecountrycaller.com/60295-microsoft-corporation-msft-windows-7-update-is-bricking-pcs/
http://www.pcper.com/news/General-Tech/Another-reason-not-use-UEFI-Secure-Boot

https://support.microsoft.com/en-us/kb/3133977

UEFI ported to RISC-V!

~ hucktech ~ 2 Comments

There’ve been a few presentations on porting UEFI to the RISC-V, but now there is public code! Abner Chang of HPE has submitted multiple patches with RISC-V support for various components of EDK-II.

[PATCH 0/3] *** EDK2 base tools support RISC-V processor***

EDK2 base tools support RISC-V arch. EDK2 build tool changes to generate RISC-V PE/Coff image from RISC-V ELF file, handle RISC-V relocations and generate EDK2 FW with RISC-V image machine type.

BaseTools: Support build RISC-V PE/Coff image.
 
The changes on BaseTools is for building RISC-V ELF image and PE/Coff Image. Also to generate FW and FV for RISC-V arch.     

[PATCH 0/2] *** EDK2 MDE for RISC-V processor ***

MdePkg: MDE implementations for RISC-V arch. The implementations of RISC-V MDE base libraries.

    Add RISC-V architecture image file machine code.
    Add RISC-V architecture relocation type.    
    Add RISC-V architecture context buffer.
    Add RISC-V architecture exception types.
    Add RISC-V architecture PXE tag definition.    
    Add RISC-V architecture EFI image machine type.
    Add RISC-V architecture removable media boot path.
    Add RISC-V architecture processor binding.
    
[PATCH] OvmfPkg/PciHostBridgeDxe: [RISC-V] Add back OVMF PciHostBridge module.

Use OVMF PCI host bridge driver as the RISC-V platform BUS.
This driver is used by RISC-V Virtualization package (RiscVVirtPkg).
Currently the platfrom spec for RISC-V is not yet ready, thus we use PCI host bridge in temporarily.

[PATCH] RiscVVirtPkg: RISC-V QEMU package.

This is RISC-V QEMU package. The image which built from this package can be launched on QEMU RISC-V port (not official QEMU). RiscVVirtPkg utilizes below modules from EDK2 OVMF package,
 – PciHostBridge DXE driver.
   Use PCI host bridge driver as RISC-V platform bus spec for adopting PC/AT components.
 – QemuFwCfgLib
   QEMU firmware configuration.
 – OVMF ACPI timer lib.
 – QemuFlashFvbServicesRuntimeDxe
 – QemuVideoDxe
 – XenIoPciDxe

[PATCH] RiscVPkg: RISC-V processor package.

 New processor package added to EDK2 open source for RISC-V.
 
[PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.

The implementation of RISC-V DxeIpl.

This is only the first round of these multiple patches, given initial discussion it is likely there will be another round. In the discussion for this patch, it appears there is more support upcoming, not yet public. In the thread, Abner mentioned:

“The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I have been told to upstream RISC-V code first and then submit the spec. I will confirm this again.”

I am looking forward to seeing what happens with the RISC-V UEFI port, and seeing some consumer devices based on RISC-V!

For more info, see the various threads on the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

List of UEFI vendors who care about security

~ hucktech ~ Leave a comment

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

AMD
AMI
Apple
Dell
Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Lenovo
Microsoft
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

http://uefi.org/security

PXE boot support added to U-Boot’s EFI payload

~ hucktech ~ Leave a comment

Alexander Graf of SuSE has submitted a new patch to his EFI payload for U-Boot, adding PXE boot support!

[PATCH 0/4] efi_loader: PXE boot support

One of the most common boot cases with EFI on arm64 is to boot from the network using PXE boot. While TianoCore implements that just fine, we were lacking support for it in U-Boot so far. But no longer! Here is a patch set, enabling PXE booting of EFI payloads. With this patch set, I was successfully able to automatically boot our normal (usually used with TianoCore based systems) environment to boot and run grub2 and a kernel from there with U-Boot.

* efi_loader: Add network access support
* bootp: Move vendor class identifier set to function
* net: Move the VCI and client arch values to Kconfig
* distro: Add efi pxe boot code

For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

Intel FSP 2.0

~ hucktech ~ 1 Comment

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment Intel.com is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

many EFI changes in Linux 4.7 queue

~ hucktech ~ Leave a comment

Matt Fleming posted a 40-part (!) patch, with the queue of UEFI changes for Linux 4.7 kernel. Edited version of Matt’s part0 comments follow:

Folks, here’s the queue of EFI material for v4.7. This is probably the biggest EFI pull ever sent, and there quite a few different topics covered. On the plus side the majority of new features (EFI Memory Attribute tables, EFI capsules, GOP framebuffer) are basically architecture independent, and some of the existing architecture-specific code has been generalised and moved to drivers/firmware/efi.

 * Drop the unused EFI_SYSTEM_TABLES efi.flags bit and ensure the ARM/arm64 EFI System Table mapping is read-only
 * Add a comment to explain that one of the code paths in the x86/pat code is only executed for EFI boot
 * Improve Secure Boot status checks on arm64 and handle unexpected errors
 * Remove the global EFI memory map variable ‘memmap’ as the same information is already available in efi::memmap
 * EFI Memory Attribute table support for ARM/arm64
 * EFI GOP framebuffer support for ARM/arm64
 * EFI Bootloader Control driver for storing reboot(2) data in EFI variables for consumption by bootloaders
 * Core EFI capsule support
 * EFI capsule char driver
 * EFI memory map code unification for ARM and arm64
 * Add generic EFI support for detecting when firmware corrupts cpu status register bits (like IRQ flags) when performing EFI runtime service calls

Ard Biesheuvel (19):
      efi: Get rid of EFI_SYSTEM_TABLES status bit
      efi/arm*: Drop writable mapping of the UEFI System table
      efi: Check EFI_MEMORY_DESCRIPTOR version explicitly
      efi/arm*: Use memremap() to create the persistent memmap mapping
      ARM: efi: Apply strict permissons for UEFI Runtime Services regions
      arm64: efi: Apply strict permissons for UEFI Runtime Services regions
      efi: Add support for the EFI_MEMORY_ATTRIBUTES_TABLE config table
      efi: Implement generic support for the Memory Attributes table
      efi/arm*: Take the Memory Attributes table into account
      x86/efi: Prepare GOP handling code for reuse as generic code
      efi/libstub: Move Graphics Output Protocol handling to generic code
      x86/efi: efifb: Move DMI based quirks handling out of generic code
      efifb: Use builtin_platform_driver and drop unused includes
      arm64/efi: libstub: Make screen_info accessible to the UEFI stub
      efi/arm: libstub: Make screen_info accessible to the UEFI stub
      efi/arm*: libstub: Wire up GOP protocol to struct screen_info
      efi/arm*: Wire up struct screen_info to efi-framebuffer platform device
      efifb: Enable the efi-framebuffer platform driver for ARM and arm64
      efi/arm-init: Reserve rather than unmap the memory map for ARM as well

Compostella, Jeremy (1):
      efibc: EFI Bootloader Control

Kweh, Hock Leong (1):
      efi: A misc char interface to update EFI firmware

Linn Crosetto (2):
      efi/arm64: Report unexpected errors when determining Secure Boot status
      efi/arm64: Check SetupMode when determining Secure Boot status

Mark Rutland (10):
      efi/runtime-wrappers: Add {__,}efi_call_virt templates
      arm64/efi: Move to generic {__,}efi_call_virt
      arm/efi: Move to generic {__,}efi_call_virt
      x86/efi: Move to generic {__,}efi_call_virt
      efi/runtime-wrappers: Remove redundant ifdefs
      efi/runtime-wrappers: Detect firmware irq flag corruption
      arm64/efi: Enable runtime call flag checking
      arm/efi: Enable runtime call flag checking
      x86/efi: Enable runtime call flag checking
      efi/runtime-wrappers: Remove ARCH_EFI_IRQ_FLAGS_MASK ifdef

Matt Fleming (7):
      x86/mm/pat: Document the (currently) EFI-only code path
      efi: Iterate over efi.memmap in for_each_efi_memory_desc
      efi: Remove global ‘memmap’
      x86/efi: Remove the always true EFI_DEBUG symbol
      efi: Move efi_status_to_err() to drivers/firmware/efi/
      efi: Capsule update support
      x86/efi: Force EFI reboot to process pending capsules

For the full patch, see the Linux-EFI mailing list archives:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
http://vger.kernel.org/majordomo-info.html