Tag: Linux

FWTS 16.07.00 released

~ hucktech ~ Leave a comment

Ivan Hu of Canonical announced the release of FirmWare Test Suite 16.07.00:

New Features:
   * acpi: method: add _FIT test
   * acpi: pcct: add ACPI PCCT test
   * opal/prd_info: Add OPAL Processor Recovery Diagnostics
   * olog: olog.json: Add OPAL skiboot errors for olog scan
   * Add klog checking for errors from drivers/acpi/tables.c
   * klog: data.json: Add klog checking for kernel NUMA errors from drivers/acpi/numa.c
   * klog: data.json: Add klog checking for kernel EC errors from drivers/acpi/ec.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/acpi_cmos_rtc.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/nfit.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/pci_root.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/pci_mcfg.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/cppc_acpi.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/battery.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/processor_idle.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/sleep.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/acpica/rsmisc.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/evged.c
   * efi: enable module loading to load legacy or new efi driver
   * acpi: madt: Add support for ACPI 6.0a
   * acpi: madt: Add support for ACPI 6.1
   * uefi: update reset type to uefi 2.6
   * acpi: dbg2: Add missing debug port types

See the full release notes for list of bugfixes.

http://fwts.ubuntu.com/release/fwts-V16.07.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.07.00
https://launchpad.net/ubuntu/+source/fwts

additional Apple device property support for Linux efistub

~ hucktech ~ Leave a comment

Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.

Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]

For more info:
https://github.com/l1k/linux/commits/apple_properties_v1
http://vger.kernel.org/majordomo-info.html

Guidance on using ACPI _DSD with Linux

~ hucktech ~ Leave a comment

Al Stone of Red Hat submitted a 4-part patch to the Linux-ACPI list. Excerpt from comments from the first patch:

How to Use the ACPI _DSD Device Properties UUIDs

In the three documents that follow, we lay out a process for defining the use cases of device properties returned by the ACPI _DSD (Device Specific Data) object in Data Structures associated with the Device Properties UUID [0] and the Hierarchical Properties Extension UUID. The term “_DSD device properties” below refers to the data formats associated with those two UUIDs only.  All other UUIDs used with _DSD are outside the scope of what is described here. The goal of these documents is to: (1) make clear to OS vendors which of the use cases of _DSD device properties need to be supported; (2) be clear on what those use cases should mean to the OS; and, (3) have all OSs use the same definitions for those use cases. The first document describes basic context and essential terminology for the process of submitting a use case for the _DSD device properties to a central location so that it can be reviewed and tracked. The next document describes a database for storing the use cases of _DSD device properties that have been reviewed and agreed upon.  The idea is to make this database publicly available so that OS developers and firmware creators can easily see what is already defined, what is in use, and what is not defined. The final document provides a formal language for describing the use cases of _DSD device properties.  The goal is to make it relatively easy to define new use cases of the _DSD device properties, by stating clearly what those definitions must look like.  This also makes building automated tools easier, allowing us to keep the process simpler, permit validation of the content, assist with documentation, and perform basic record keeping. […]

See full post and the github project:

https://github.com/ahs3/dsd/tree/master/documentation
https://marc.info/?l=linux-acpi&m=146955102920815&w=2
https://marc.info/?l=linux-acpi&m=146955096920780&w=2
https://marc.info/?l=linux-acpi&m=146955089620763&w=2
https://marc.info/?l=linux-acpi&m=146955077420741&w=2
https://marc.info/?l=linux-acpi&m=146955067620727&w=2

Also, there’s a Python-based _DSD command line tool in the same DSD github project!

https://github.com/ahs3/dsd

Enterprise: a UEFI boot loader for Linux

~ hucktech ~ Leave a comment

‘Enterprise’ is the name of a UEFI boot loader that is meant to boot 1 or more Linux ISOs off a USB thumbdrive. The last release was back in 2015, but there is recent Github code activity. SevenBits created ‘Enterprise’, in addition to ‘Mac Linux USB Loader’, which sets up a bootable USB with Enterprise.

Enterprise (named after the Starship Enterprise from Star Trek) is an EFI program that is designed to assist in booting Linux distributions from USB sticks on UEFI-based PCs and Macs, something that is continously regarded as being near to impossible due to quirks in vendors’ EFI implementations and really quite poor support from Linux distributions.  Using Enterprise, you can create bootable USB drives that boot on a UEFI-based computer without needing rEFIt or rEFInd to be installed.  Originally designed to compliment ‘Mac Linux USB Loader’, Enterprise can also be used on its own to boot Linux on a variety of UEFI-based PCs and Macs.  The purpose of Enterprise is as the first stage in a two-stage booting process for ‘Mac Linux USB Loader’-created USB drives. Enterprise is a custom UEFI boot manager designed to load Linux distributions, even those without UEFI booting support, directly from ISO files on UEFI-based computers.  Enterprise provides an easy-to-use and simplistic interface that automates many of the tasks necessary to boot distributions of Linux from an ISO file.  Enterprise supports booting multiple distributions, so you can have more than one distribution per USB stick and multiple configurations for each distribution. Enterprise requires a configuration file telling it about which distributions it should load. This configuration file is created automatically when you use tools like Mac Linux USB Loader, though it is possible to write your own file and configure Enterprise as one would configure other boot managers such as GRUB, gummiboot, and syslinux, albeit much more simply.  Enterprise is under the LGPL; it pulls in code from other software projects (namely, gummiboot). It is written in portable C, and can be compiled to run on both 32-bit and 64-bit EFI firmware types.

https://www.sevenbits.tk/
https://github.com/SevenBits/Enterprise
https://sevenbits.github.io/Mac-Linux-USB-Loader/

ACPI/APEI BERT support for Linux

~ hucktech ~ Leave a comment

Tony Luck of Intel submitted a patch to the Linux (Kernel,ACPI) lists, to add ACPI BERT (Boot Error Record Table) support to the Linux kernel. The original patch appears to be from Huang Ying of Intel, I think.

New Linux kernel parameter:
bert_disable: Disable BERT OS support on buggy BIOSes.

Excerpting comments from the patch:

ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf

The following log is a BERT record after system reboot because of hitting a fatal memory error:
BERT: Error records from previous boot:
[Hardware Error]: It has been corrected by h/w and requires no further action
[Hardware Error]: event severity: corrected
[Hardware Error]:  Error 0, type: recoverable
[Hardware Error]:   section_type: memory error
[Hardware Error]:   error_status: 0x0000000000000400
[Hardware Error]:   physical_address: 0xffffffffffffffff
[Hardware Error]:   card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
[Hardware Error]:   error_type: 2, single-bit ECC

For more information, see the patch message thread on the Linux-kernel list:
http://vger.kernel.org/majordomo-info.html

NVMe-over-Fabrics support added to Linux

~ hucktech ~ Leave a comment

Christoph Hellwig has submitted multiple patches Linux’s existing NVMe support to enable ‘NVMe over Fabrics’ support. I’ve included his initial comments for each of the 4 patches:

—–

general preparation for NVMe over Fabrics support

This patch set adds some needed preparations for the upcoming NVMe over Fabrics support. Contains:
– Allow transfer size limitations for NVMe transports
– Add the get_log_page command definition required by the NVMe target
– more helpers in core code that can be used by various transports
– add some missing constants and identify attributes

—–

NVMe over Fabrics target implementation

This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over Fabrics access to Linux block devices. The target implementation consists of several elements:
– NVMe target core:  defines and manages the NVMe entities (subsystems, controllers, namespaces, …) and their allocation, responsible for initial commands processing and correct orchestration of the stack setup and tear down.
– NVMe admin command implementation: responsible for parsing and servicing admin commands such as controller identify, set features, keep-alive, log page, …).
– NVMe I/O command implementation: responsible for performing the actual I/O (Read, Write, Flush, Deallocate (aka Discard).  It is a very thin layer on top of the block layer and implements no logic of it’s own. To support exporting file systems please use the loopback block driver in direct I/O mode, which gives very good performance.
– NVMe over Fabrics support: responsible for servicing Fabrics commands (connect, property get/set).
– NVMe over Fabrics discovery service: responsible to serve the Discovery log page through a special cut down Discovery controller.

The target is configured using configfs, and configurable entities are:
 – NVMe subsystems and namespaces
 – NVMe over Fabrics ports and referrals
 – Host ACLs for primitive access control – NVMe over Fabrics access control is still work in progress at the specification level and will be implemented once that work has finished.

To configure the target use the nvmetcli tool from http://git.infradead.org/users/hch/nvmetcli.git, which includes detailed setup documentation.

In addition to the Fabrics target implementation we provide a loopback driver which also conforms the NVMe over Fabrics specification and allows evaluation of the target stack with local access without requiring a real fabric.

Various test cases are provided for this implementation: nvmetcli contains a python testsuite that mostly stresses the configfs interface of the target, and we have various integration tests prepared for the kernel host and target which are available at:

    git://git.infradead.org/nvme-fabrics.git nvmf-selftests
    http://git.infradead.org/nvme-fabrics.git/shortlog/refs/heads/nvmf-selftests

This repository also contains patches from all the series posted today in case you prefer using a git repository over collecting patches.

NVMe over Fabrics RDMA transport drivers

This patch set implements the NVMe over Fabrics RDMA host and the target drivers. The host driver is tied into the NVMe host stack and implements the RDMA transport under the NVMe core and Fabrics modules. The NVMe over Fabrics RDMA host module is responsible for establishing a connection against a given target/controller, RDMA event handling and data-plane command processing. The target driver hooks into the NVMe target core stack and implements the RDMA transport. The module is responsible for RDMA connection establishment, RDMA event handling and data-plane RDMA commands processing. RDMA connection establishment is done using RDMA/CM and IP resolution. The data-plane command sequence follows the classic storage model where the target pushes/pulls the data.

generic NVMe over Fabrics library support

This patch set adds the necessary infrastructure for the NVMe over Fabrics functionality and the NVMe over Fabrics library itself. First we add some needed parameters to NVMe request allocation such as flags (for reserved commands – connect and keep-alive), also support tag allocation of a given queue ID (for connect to be executed per-queue) and allow request to be queued at the head of the request queue (so reconnects can pass in flight I/O). Second, we add support for additional sysfs attributes that are needed or useful for the Fabrics driver. Third we add the NVMe over Fabrics related header definitions and the Fabrics library itself which is transport independent and handles Fabrics specific commands and variables. Last, we add support for periodic keep-alive mechanism which is mandatory for Fabrics.

For more information, see the linux-(nvme,block,kernel) mailing lists.
http://lists.infradead.org/mailman/listinfo/linux-nvme

AllWinner ARM Linux backdoor???

~ hucktech ~ Leave a comment

I don’t know anything more about this story…

“Chinese ARM vendor’s Kernel root backdoor snippet”

“Allwinner […] apparently shipped a version of its Linux kernel with a backdoor built in.”

https://wikicoding.org/wiki/c/Kernel_root_backdoor_snippet/

Description of Xen exploit XSA-105

~ hucktech ~ Leave a comment

Jérémie Boutoille has a new blog post with information on Xen, with a video at the beginning for those who are too busy to read the entire article:

Xen exploitation part 1: XSA-105, from nobody to root

This blog post describes the exploitation of Xen Security Advisory 105 (XSA-105)  (CVE-2014-7155). This post explains the environment setup and shows the development of a fully working exploit on Linux 4.4.5. We are not aware of any public exploit for this vulnerability, although Andrei Lutas wrote excellent articles  describing the root cause of the vulnerability and how to trigger it. This post explains the environment setup and shows the development of a fully working exploit on Linux 4.4.5 (it probably works with many others versions). […]

http://blog.quarkslab.com/xen-exploitation-part-1-xsa-105-from-nobody-to-root.html

AFL support added to Linux Kernel

~ hucktech ~ Leave a comment

https://twitter.com/lcamtuf/status/734055720010670080

The Linux kernel just got a patch to add AFL support! I don’t believe FreeBSD has such a feature, yet…. 😐

[PATCH] kcov: add AFL-style tracing

AFL uses a fixed-size buffer (typically 64 KiB) where each byte is a counter representing how many times an A -> B branch was taken. Of course, since the buffer is fixed size, it’s a little imprecise in that e.g. two different branches could map to the same counter, but in practice it works well.

See afl:docs/technical_details.txt for more information.

http://lkml.iu.edu/hypermail/linux/kernel/1605.2/03665.html

ubuntu-secure-boot package

~ hucktech ~ Leave a comment

James Johnson has a project to help make Secure Boot on Ubuntu. Excerpt of readme:

ubuntu-secure-boot package

The stock Ubuntu 15.10 installation only implements secure boot just enough to get a Microsoft-signed shim in place.  It does nothing to actually secure the boot process.  This package can help users do so.

Features of ubuntu-secure-boot:
* Self-signed bootloader files: take control over your boot process by stripping Canonical / Microsoft signatures from your boot files and signing everything yourself.
* Summary of files that are digitally signed and verified during the boot process are:
    * GRUB itself (self-signed)
    * GRUB configuration (self-signed)
    * GRUB modules and other external files (self-signed)
    * Linux kernel (self-signed)
    * Linux initramfs / initrd (self-signed)
    * Linux kernel modules (using existing Canonical signatures)
* Self-signed private keys are stored in /etc/ubuntu-secure-boot/keys and protected by a passphrase.
* UEFI Secure Boot self-signed key pairs are generated and used to sign the self-contained GRUB .efi image.  They can be imported into a UEFI firmware  to take full control over the secure boot process.
* The secure GRUB image is added as a boot option in EFI firmware.
* Digital signature support in GRUB is enabled to check signatures on any boot file that is loaded from disk.  The risk of loading an unsigned file from GRUB is eliminated (e.g. an unsigned kernel).
* GRUB is now deployed as a stand-alone .efi image that contains a memdisk with the full configuration and all loadable modules.  This eliminates the risk of tampering with the GRUB configuration.
* GRUB is automatically locked down with a password so that users cannot tamper with boot settings or use advanced boot options.
* Unsigned GRUB files in /boot remaining from the original GRUB packages are completely wiped (but restored upon uninstall of this package).
* Newly-installed kernels are automatically signed whenever they are installed. Existing Canonical .efi signatures in the linux-signed-image-* packages are stripped and replaced with your signature.
* The initramfs is automatically re-signed whenever update-initramfs is run.
* Linux kernel module signing enforcement is automatically enabled by default. This can be controlled from /etc/default/grub.d/ubuntu-secure-boot.cfg.

https://github.com/JohnstonJ/ubuntu-secure-boot

UEFIOP

~ hucktech ~ Leave a comment

Ivan Hu of Canonical has two related projects on Github, UEFIOP and EFI_runtime, the former app depends on the latter Linux kernel driver:

The uefiop is an application that allows users to manipulate UEFI runtime interfaces provided by Bios at runtime. Current capabilities:
 * set and delete uefi variables

The Efi_runtime kernel driver module aims to provide the interfaces for fwts (firmware test suite) to test the UEFI Runtime services provide by firmware. Current capabilities:
 * provide the RT service interfaces:
 * GetVariable
 * SetVariable
 * GetTime
 * SetTime
 * GetWakeupTime
 * SetWakeupTime
 * GetNextVariableName

https://github.com/Ivanhu5866/uefiop
https://github.com/Ivanhu5866/efi_runtime

FWTS 16.05.01 released

~ hucktech ~ Leave a comment

Alex Hung of Canonical has announced the 16.05.01 release of FWTS, the FirmWare Test Suite.

There are new ACPI and IPMI and TCG OVAL and Linux device-tree tests. In addition to new features, there’s an even larger list of bugfixes for most classes (UEFI, BIOS, ACPI, etc.) of tools, not excerpted below, see the full announcement for those.

New Features:
  * acpi: add MSCT table sanity check
  * acpi: add EINJ table sanity check
  * ACPICA: Update to version 20160318 (LP: #1559312)
  * Introduce olog scan, to check OPAL msglog.
  * Introduce IPMI BMC Info
  * devicetree: add infrastructure for device-tree tests
  * devicetree/dt_sysinfo: Add device tree system information tests
  * devicetree/dt_base: Add base device-tree validity checks
  * debian/control: change depends on libjson0-dev to libjson-c-dev
  * auto-packager: mkpackage.sh: add yakkety and remove vivid
  * debian/control: add back libjson0-dev for precise

http://fwts.ubuntu.com/release/fwts-V16.05.01.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.05.01
https://launchpad.net/ubuntu/+source/fwts

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/

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.

Reversing Huawei router part 2: U-Boot’s CLI

~ hucktech ~ Leave a comment

Juan Carlos Jiménez has written the 2nd part of his series on reversing a Huawei router! The first part was excellent, this one is just as good.

Practical Reverse Engineering Part 2 – Scouting the Firmware

In part 1 we found a debug UART port that gave us access to a linux shell. At this point we’ve got the same access to the router that a developer would use to debug issues, control the system, etc. This first overview of the system is easy to access, doesn’t require expensive tools and will often yield very interesting results. If you want to do some hardware hacking but don’t have the time to get your hands too dirty, this is often the point where you stop digging into the hardware and start working on the higher level interfaces: network vulnerabilities, ISP configuration protocols, etc. […]

Part 2:
http://jcjc-dev.com/2016/04/29/reversing-huawei-router-2-scouting-firmware/

Part 1:

Huawei HG533 reversing, part I


http://jcjc-dev.com/2016/04/08/reversing-huawei-router-1-find-uart/

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