Linux 4.10 UEFI changes

Matt Fleming posted UEFI changes for Linux 4.10 kernel.

Folks, please pull the following v4.10 material. There isn’t a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook.
 * Fix an allocation bug in the generic EFI libstub where alignment and adjusted size isn’t taken into account – Roy Franz
 * Update the EFI MAINTAINERS entry to include ARM and arm64 files and directories – Ard Biesheuvel
 * Add new feature to seed the RNG from the stashed value returned by EFI_RNG_PROTOCOL in EFI stub and wire up for ARM/arm64 – Ard Biesheuvel
 * Retrieve Apple device properties from within the EFI stub to fully support thunderbolt devices on Apple Macbooks – Lukas Wunner

More details on the Thunderbolt patch:

thunderbolt: Use Device ROM retrieved from EFI:
Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is empty with uid 0x1000000000000. (Apple started factory-burning a unit- specific DROM with Thunderbolt 2.) Instead, the NHI EFI driver supplies a DROM in a device property. Use it if available. It’s only available when booting with the efistub.  If it’s not available, silently fall back to our hardcoded DROM.  The size of the DROM is always 256 bytes. The number is hardcoded into the NHI EFI driver. This commit can deal with an arbitrary size however, just in case they ever change that.  Background information: The EFI firmware volume contains ROM files for the NHI, GMUX and several other chips as well as key material. This strategy allows Apple to deploy ROM or key updates by simply publishing an EFI firmware update on their website. Drivers do not access those files directly but rather through a file server via EFI protocol AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818.  The NHI EFI driver amends that file with a unit-specific uid. The uid has 64 bit but its entropy is much lower: 24 bit represent the model, 24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI driver obtains the serial number via the DataHub protocol, copies it into the DROM, calculates the CRC and submits the result as a device property.  A modification is needed in the resume code where we currently read the uid of all switches in the hierarchy to detect plug events that occurred during sleep. On Thunderbolt 1 root switches this will now lead to a mismatch between the uid of the empty DROM and the EFI DROM. Exempt the root switch from this check: It’s built in, so the uid should never change. However we continue to *read* the uid of the root switch, this seems like a good way to test its reachability after resume.
git:// tags/efi-next

EFI changes for Linux v4.9

Matt Fleming sent a message to Linux Kernel/EFI lists with a set of UEFI-centric patches for Linux 4.9. Excerpting his message:

[…]There’s more work on refactoring EFI code to be architecture independent and the largest number of patches is spent cleaning up the EFI memory map code and allowing drivers on x86 to reserve EFI boot services for all of runtime. The architecture independent quest is going pretty well and it was only a couple of lines to get the esrt driver working on arm64. Other than that there’s some cleanups and fixes, and a merge of the out of tree EFI runtime driver from the FWTS project.

 * Refactor the EFI memory map code into architecture neutral files and allow drivers to permanently reserve EFI boot services regions on x86, as well as ARM/arm64 – Matt Fleming
 * Add ARM support for the EFI esrt driver – Ard Biesheuvel
 * Make the EFI runtime services and efivar API interruptible by swapping spinlocks for semaphores – Sylvain Chouleur
 * Provide the EFI identity mapping for kexec which allows kexec to work on SGI/UV platforms with requiring the “noefi” kernel command line parameter – Alex Thorlton
 * Add debugfs node to dump EFI page tables on arm64 – Ard Biesheuvel
 * Merge the EFI test driver being carried out of tree until now in the FWTS project – Ivan Hu
 * Expand the list of flags for classifying EFI regions as “RAM” on arm64 so we align with the UEFI spec – Ard Biesheuvel
 * Optimise out the EFI mixed mode if it’s unsupported (CONFIG_X86_32) or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot services function table for direct calls, alleviating us from having to maintain the custom function table – Lukas Wunner
 * Miscellaneous cleanups and fixes

git:// tags/efi-next

Linux UEFI updates for Linux 4.7

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:
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.

many EFI changes in Linux 4.7 queue

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:// tags/efi-next

LinuxCon Europe UEFI Mini-Summit presentations available

Earlier this month, the UEFI Forum recently had a “Mini-Summit” at LinuxCon Europe. The presentations are now available online (so far just the slides, unclear if A/V will show up on Youtube later):

UEFI Mini-Summit at LinuxCon Europe: October 7, 2015

* UEFI Forum Update and Open Source Community Benefits – Mark Doran (Intel)
* What Linux Developers Need to Know About Recent UEFI Spec Advances – Jeff Bobzin (Insyde Software)
* LUV Shack: An Automated Linux Kernel and UEFI Firmware Testing Infrastructure – Matt Fleming (Intel)
* Goodbye PXE, Hello HTTP Boot – Dong Wei (HP)
* UEFI Development in an Open Source Ecosystem – Michael Krau (Intel)

More information (about halfway down the page, past the Youtube section):



The Embedded Linux Conference Europe (ELCE) is happening in October. There’s a set of UEFI talks happening at the event:

UEFI Forum Update and Open Source Community Benefits, Mark Doran

Learn about the recent UEFI Forum activities and the continued adoption of UEFI technology. To ensure greater transparency and participation from the open source community, the Forum has decided to allow for public review of all specification drafts. Find out more about this new offering and other benefits to being involved in firmware standards development by attending this session.   

What Linux Developers Need to Know About Recent UEFI Spec Advances, Jeff Bobzin

Users of modern client and server systems are demanding strong security and enhanced reliability. Many large distros have asked for automated installation of a local secure boot profile. The UEFI Forum has responded with the new Audit Mode specified in the UEFI specification, v2.5, offering new capabilities, enhanced system integrity, OS recovery and firmware update processes. Attend this session to find out more about the current plans and testing schedules of the new sample code and features.

LUV Shack: An automated Linux kernel and UEFI firmware testing infrastructure, Matt Fleming

The Linux UEFI Validation (LUV) Project was created out of necessity. Prior to it, there was no way to validate the interaction of the Linux kernel and UEFI firmware at all stages of the boot process and all levels of the software stack. At Intel, the LUV project is used to check for regressions and bugs in both eh Linux kernel and EDK2-based firmware. They affectionately refer to this testing farm as the LUV shack. This talk will cover the LUV shack architecture and validation processes.

The Move from iPXE to Boot from HTTP, Dong Wei

iPXE relies on Legacy BIOS which is currently is deployed by most of the world’s ISPs. As a result, the majority of x86 servers are unable to update and move to a more secure firmware platform using UEFI. Fortunately, there is a solution. Replacing iPXE with the new BOOT from HTTP mechanism will help us get there. Attend this session to learn more.

UEFI Development in an Open Source Ecosystem, Michael Krau, Vincent Zimmer

Open source development around UEFI technology continues to progress with improved community hosting, communications and source control methodologies. These community efforts create valuable opportunities to integrate firmware functions into distros. Most prevalent UEFI tools available today center on chain of trust security via Secure Boot and Intel® Platform Trust Technology (PTT) tools. This session will address the status of these and other tools. Attendees will have the opportunity to share feedback as well as recommendations for future open UEFI development resources and processes.

UEFI aside, there’s many other presentations that look interesting, for example:

Isn’t it Ironic? The Bare Metal Cloud – Devananda van der Veen, HP
Developing Electronics Using OSS Tools – Attila Kinali
How to Boot Linux in One Second – Jan Altenberg, linutronix GmbH
Reprogrammable Hardware Support for Linux – Alan Tull, Altera
Measuring and Reducing Crosstalk Between Virtual Machines – Alexander Komarov, Intel
Introducing the Industrial IO Subsystem: The Home of Sensor Drivers – Daniel Baluta, Intel
Order at Last: The New U-Boot Driver Model Architecture – Simon Glass, Google
Suspend/Resume at the Speed of Light – Len Brown, Intel
The Shiny New l2C Slave Framework – Wolfram Sang
Using seccomp to Limit the Kernel Attack Surface – Michael Kerrisk
Tracing Virtual Machines From the Host with trace-cmd virt-server – Steven Rostedt, Red Hat
Are today’s FOSS Security Practices Robust Enough in the Cloud Era – Lars Kurth, Citrix
Security within Iotivity – Sachin Agrawal, Intel
Creating Open Hardware Tools – David Anders, Intel
The Devil Wears RPM: Continuous Security Integration – Ikey Doherty, Intel
Building the J-Core CPU as Open Hardware: Disruptive Open Source Principles Applied to Hardware and Software – Jeff Dionne, Smart Energy Instruments
How Do Debuggers (Really) Work – Pawel Moll, ARM
Make your Own USB device and Driver with Ease! – Krzysztof Opasiak, Samsung
Debugging the Linux Kernel with GDB – Peter Griffin, Linaro