docker-edk2-uefi: Docker container for Tianocore EDK2 dev

Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh

UEFI EDKII Development Environment

This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]

https://hub.docker.com/r/geneerik/docker-edk2-uefi/

Somewhat related, I also found these UEFI/Docker options:

https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/

PS: Wondering what he’s been messing with UEFI on:

 

UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:

http://wiki.qemu.org/ChangeLog/2.9

The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

Windows UEFI development course

WinInsider — probably via Alex Ionescu — has a UEFI development course available.  Alex is the author of VisualUEFI, which hides the non-Visual Studio’isms of EDK-II development. Alex, along with others at Wininternals, is also one of the current authors of the “Windows Internals”  book from Microsoft Press, now a 2-volume 6th edition set, originally called “Inside Windows NT”, written by Helen Custer.

Windows UEFI Development (3 Days or 5 Days)

In this course, one can expect to learn the internals of the Unified Extensible Firmware Interface inside and out, from the high-level concepts and overview of its functionality, down to the low-level development of actual UEFI applications, drivers, and services. The seminar will go over the history of UEFI’s development, from its original “Intel Boot Initiative” days to today’s SecureBoot facilities (and controversies), discuss the core UEFI data structures that form the basis of the environment, describe the different internal boot phases of the UEFI Runtime, and go in detail over the main UEFI protocols and their semantics. The course will also cover how UEFI leverages several Microsoft technologies, such as Authenticode and the Portable Executable (PE) format. Finishing off the lecture section will be a deep dive on how Windows 8 and later take advantage of UEFI to support booting off GPT disks, implementing SecureBoot, and speeding up the boot experience. Windows user-mode and kernel-mode APIs that interact with UEFI, as well as internal kernel data structures and capabilities in the UEFI HAL will also be shown off. Alongside the lecture period, attendees will get their hands dirty with bare-to-the-metal UEFI development using Visual Studio, as well as learning how to setup the UEFI SDK (EDK) to work alongside Microsoft’s development tools. Participants will get the chance to build their own UEFI applications, drivers, and runtime services, as well as learn how to debug and test their work in the OVMF environment alongside QEMU, without requiring actual UEFI hardware. The course will also show how to develop and build SecureBoot-compatible binaries. Finally, attendees will discover the Windows-specific Boot Application Runtime Environment, how to build compatible applications, and how to leverage the environment from both a UEFI and PCAT perspective. Attendees will then write both offensive and defensive UEFI code that hooks and/or protects the Windows Boot Loader.

UEFI Course Outline:
* Introduction to UEFI
* UEFI Architecture
* UEFI Protocols & Services
* Windows and UEFI
* Windows Boot Application Environment
* Windows Boot Loader Internals
* EDK and Visual Studio Development
* Windows & UEFI Interfacing

Topics:
* UEFI Protocols: UEFI Device Handles, UEFI Text and Graphics, UEFI Local and Remote I/O, UEFI USB & PCI, UEFI File System, Custom Protocols
* UEFI Services: UEFI Boot Services & Runtime Services, UEFI System Table, ACPI & UEFI, Custom Services
* UEFI Architecture: Measured Boot & Secure Boot, UEFI Stages & Layers (SEC, PEI, DXE), GPT Partitioning, Types of UEFI Binaries
* Windows & UEFI: Calling UEFI Services, Accessing UEFI Variables, Windows Boot Library and UEFI, BCD and UEFI, HAL and UEFI
* Windows Boot Environment: PCAT and UEFI Portability, Core Data Structures, Entrypoint and Callbacks,  Building a Windows Boot Application
* Windows Boot Loader: Boot Stages, Boot Loader Functionality, Security Services (BitLocker and more), Boot Structures, Handoff to Kernel
* UEFI Development: Obtaining and Installing the EDK, Setting up Visual Studio with the EDK, EDK Hello World, Interfacing with EDK Libraries, Obtaining and Installing OVMF
* Offensive UEFI: Hooking UEFI Services and Protocols, Windows Boot Environment Hooks, Persistence with UEFI
* Defensive UEFI: Checking for Boot Loader Integrity, Detecting UEFI Hooks and Bootkits

http://www.windows-internals.com/?page_id=1673

http://www.alex-ionescu.com/

Virt-Manager updated with UEFI (OVMF/AVMF) support

Virt-Manager, as of 1.2, has support for UEFI’s OVMF/AVMF format!

http://www.phoronix.com/scan.php?page=news_item&px=UEFI-OVMF-Virt-Manager-1.2
http://blog.wikichoon.com/2016/01/uefi-support-in-virt-install-and-virt.html
http://www.phoronix.com/scan.php?page=news_item&px=Virt-Manager-1.2-Released
https://www.redhat.com/archives/virt-tools-list/2015-May/msg00010.html
https://virt-manager.org/

I missed this news, but luckily Phoronix did not…

BTW, Virt-Manager is a SPICE client, and UEFI has some SPICE support. I don’t know what that means, I’ve been meaning to learn… 🙂 There is information on this in the below OVMF whitepaper:

http://www.spice-space.org/
http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

Laszlo’s OVMF SMM patch status

Laszlo Ersek of Red Hat has a huge patch to Tianocore, which adds SMM to OVMF, and just posted a detailed status update to the EDK2-devel mailing list, The current test results of patch look impressive! Pretend the following table is using a fixed font:

  accel  bits  guest OS         OS boots  efibootmgr works on  S3 resume
  —–  —-  —————  ——–  ——————-  ———
  TCG    32    Fedlet 20141209  pass[1]   BSP and AP           pass
  TCG    64    F21 XFCE LiveCD  pass[1]   BSP and AP           fail[2]
  KVM    32    Fedlet 20141209  pass      BSP and AP           pass
  KVM    64    F21 XFCE LiveCD  pass      BSP and AP           fail[2]
  KVM    64    Windows 8.1      pass      n/a                  fail[2]

I’ve excerpted the key items from the TODO section of the status report: 🙂

* TODO:
– celebrate a bit this weekend (look at that “OS boots” column!)
– celebrate some more?

Full status report (including most of the details, and the omitted footnotes listed above):

http://article.gmane.org/gmane.comp.bios.edk2.devel/3357

(Also note that the EDK2-devel mailing list, which recently moved from SourceForge.net to Intel’s 01.org, is now hosted on Gmane under the gmane.bios.edk2 namespace. The previous SourceForge list is listed under the gmane.bios.tianocore namespace.)

new tool: Visual UEFI for Windows

Alex Ionescu just created a new project to help with Visual Studio / EDK-II integration.

https://github.com/ionescu007/VisualUefi

Excerpting from it’s readme, VisualUEFI is 3 things:

1) a Solution and set of Visual Studio 2015 Project Files to allow building the official EDK-II without the use of inf files, Python and 50 other build tools, a custom dependency tracker and build system, and twenty other custom pieces of code. The EDK-II is present as a submodule, directly from the official TianoCore Tree, and no changes are done to it.
2) a Solution and couple of Visual Studio 2015 Project Files to show two UEFI sample components: A UEFI Application, and a UEFI Boot Driver. The code is 100% EDK-II compatible, but built with VisualUEFI instead.
3) a working copy of QEMU64 2.3 for Windows, with a fairly recent UEFI 2.5 OVMF Secure Boot ROM. These will updated on an ongoing basis as needed. This is integrated with the Visual Studio 2015 Sample Solution so that pressing F5 will spin up the instance for testing.

You should be able to open the EDK-II.SLN file and build without any issues in Visual Studio 2015. WDK or other 3rd party installations are not needed. Once the EDK-II libraries are built, you should be able to open the SAMPLES.SLN file and build the two samples, which will create UefiApplication.efi and UefiDriver.efi.

You can press F5 (Run/Debug) from within the Sample Solution, which should spin up the QEMU instance with 512MB of ram, and your release directory as a virtual file system accessible through “fs0:”. You can then try loading the driver with “Load fs0:\UefiDriver.efi”. You can verify its presence by using the Drivers or DevTree commands.

Visual UEFI looks like a nice improvement to Microsoft’s Visual Studio IDE. Thanks, Alex!

(This is the kind of thing I kept expecting the UEFI Forum to release, as an Eclipse plugin, like Yocto and some related projects have done.)

SMM for OVMF

Earlier this month, Laszlo Ersek of Redhat contributed a large patch to the TianoCore project, adding SMM support to OVMF.

“OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure, and in the UEFI variable driver stack. The purpose is (virtual) hardware separation between the runtime guest OS and the firmware (OVMF), with the intent to make Secure Boot actually secure, by preventing the runtime guest OS from tampering with the variable store and S3 areas.”

The changes require QEMU usage with these flags:

qemu-system-i386-machine q35,smm=on,accel=(tcg|kvm)-global driver=cfi.pflash01,property=secure,value=on -smp cpus=1 …

This new OVMF SMM works on the q35 machine, only in uniprocessor guests, and with TCG acceleration it only works on x86 not x64. Apparently the lack of 64-bit support is due to 64-bit code not available in TianoCore(?):

“In addition, using OvmfPkgIa32X64.dsc or OvmfPkgX64.dsc, the patch set even stops building after a point, *if* -D SMM_REQUIRE is passed. This is due to the unavailability of 64-bit open source components from Intel, and the build breakage is fully intentional — it shows that the -D SMM_REQUIRE feature is build-level incomplete for OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc, and marks precisely where further development is needed.”

More Information:

Check out the 58-part patch on the mailing list, the first and last messages have a lot more documentation:

https://lists.01.org/mailman/listinfo/edk2-devel

VirtualBox 5.0 released

Oracle relased version 5.0 of VirtualBox yesterday. I don’t see any firmware features listed in the press, and I’ve not had a chance to do a code review of the new code yet. It has improved CPU and USB 3.0 support, at minimum.

QEMU is the main platform for running UEFI’s virtual firmware: OVMF. But Xen, KVM, and VirtualBox also support OVMF, to some degree. VirtualBox can also be recompiled with EFI-specific build directives to enable additional UEFI diagnostics.

https://www.oracle.com/corporate/pressrelease/oracle-vm-virtualbox-5-070915.html

https://blogs.oracle.com/virtualization/entry/oracle_vm_virtualbox_5_07

(In somewhat related news, back in March, Oracle’s Linux distro got Secure Boot support.)

https://blogs.oracle.com/wim/entry/secure_boot_support_with_oracle

 

Red Hat OVMF whitepaper

[This is not fresh news. Since this is a new blog, I’m starting to work backward on some noteworthy news/releases that happened shortly before the blog started…]

Mid-2014, Red Hat released a whitepaper documenting the UEFI OVMF format. It is well-written, and useful for those new to UEFI, coming from a Linux background. The document is Copyright (C) 2014-2015, Red Hat, Inc., licensed CC BY-SA 4.0.

Abstract: The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is designed to replace the Basic Input/Output System (BIOS) firmware interface. Hardware platform vendors have been increasingly adopting the UEFI Specification to govern their boot firmware developments. OVMF (Open Virtual Machine Firmware), a sub-project of Intel’s EFI Development Kit II (edk2), enables UEFI support for Ia32 and X64 Virtual Machines. This paper reports on the status of the OVMF project, treats features and limitations, gives end-user hints, and examines some areas in-depth.

Keywords: ACPI, boot options, CSM, edk2, firmware, flash, fw_cfg, KVM, memory map, non-volatile variables, OVMF, PCD, QEMU, reset vector, S3, Secure Boot, Smbios, SMM, TianoCore, UEFI, VBE shim, Virtio

Read the whitepaper:

http://people.redhat.com/~lersek/ovmf-whitepaper-c770f8c.txt