Low-cost UEFI debugging options for Intel

The other day I asked on the UEFI development list about hardware options for debugging UEFI, for security researchers (many UEFI debugging solutions only target OEMs/IBVs/IHVs). I was mainly thinking about Intel Tunnel Mountain, and related widgets like the Intel ITP-XDP, and other options in addition to AMI’s AMIdebug and Arium’s ITP products. It looks interesting; previously, all I knew of was Arium’s ITP and AMI’s AMIdebug products. Some of the commercial tools (eg, Arium) have new, expensive, closed-source debuggers, and don’t enable use of existing GDB/Windbg skills.

Zachary Gray of of the Intel System Studio debugger team replied with some answers:

Tunnel Mountain is OK but it is a bit old (by Intel standards) If you are looking for a small target for UEFI research purposes I *strongly* recommend the MinnowBoard Max.  This target has a freely available firmware that is mostly public, you can compile the firmware with GCC or MSVC, it is debuggable using JTAG (Arium,  or our Intel System Studio debugger with the ITP-XDP3 probe) and it is also debuggable using the Agent-based solution that is built into the image (cheap and easy!).

With regards to Intel System Studio vs Arium, I would say that the Arium JTAG debugger has a broader feature set that is proportional to their price, but the System Studio JTAG debugger also provides a useful feature set at a lower cost.  We can debug all the UEFI code from reset to boot loader, and also into the OS if you have an interest there as well.  With any of these debug tools you do not need a special compiler, you just use a standard debuggable build of the firmware.

Another even cheaper alternative would be to debug an Intel Galileo board using a low-cost FTDI probe such as an Olimex with the OpenOCD open-source JTAG debug server.  The board + probe would be <$200 and the firmware is publicly available.  For a front-end to the OpenOCD debug server you can use either the Intel System Studio debugger, or simply use GDB.  Some google searches will lead you to some documentation on all this.  The catch is that Galileo is not a “normal” Intel CPU so depending on your research interest the firmware may not present the concepts you are interested in.

Bruce Cran also replied with a lower-cost options:

Another even cheaper alternative, if you don’t need real hardware, is qemu+OVMF. It’s what I use to debug UEFI problems with the PCI driver I  work on (using gdb).

Alternatively, if you don’t need an x86-based system, I believe the BeagleBone/BeagleBoard (with ARM CPU) can be reflashed to edk2 firmware and debugged with a Flyswatter2 – with the main problem likely being being surface-mounting the JTAG header!

I also received some more advice via private email, from a firmware security researcher. Paraphrasing, they felt that the MinnowboardMAX is not much better than the Galileo for UEFI debugging, because it has many more blobs in it’s “open source” BIOS, and the Minnow is harder to debug than Galileo, since modern Atom CPUs are complex. Their advice was low-cost debugging was Galileo over Minnow, $20 for JTAG probe, and free GDB.

Thanks for all the advice!!

Obviously, this post doesn’t cover ARM [much], just Intel and virtual solutions. I’m still learning the best options for ARM-based hardware and UEFI, and will post another article on ARM in the future.

More Information:


[UDPATE: comment from a smart reader:
AMIDebug technology is not useful for end users and researchers because it’s support should be specifically compiled in in a special DEBUG build. The AMI DebugRX hardware part is OK to get port 80h codes via USB, mediocre source-level debugging. Intel XDP or Arium-ITP are similar to AMIDebug, both nice products, and don’t require any firmware changes or special build modes.
BTW, I don’t know why Comments don’t show up on blog web site, working on trying to fix that… ]

Earlier this week AMI announced USB3 support for their AMIDebug for UEFI product.

Apparently AMI has 3 versions of this: 1) AMIDebug for UEFI software for Aptio V, 2) the AMIDebug Rx handheld USB debug device, and 3) Aptio V UEFI Firmware from AMI.

Press release excerpts:

American Megatrends, Inc. (AMI), a global leader in BIOS, remote management, network data storage products and solutions for the Android(TM) operating system, is pleased to announce support for USB 3.0 controllers in the latest release of its AMIDebug(TM) for UEFI debugging solution for Aptio(R) V UEFI Firmware.

AMIDebug for UEFI from American Megatrends is a powerful software-based solution for debugging UEFI projects based on Aptio or the UEFI Shell, offering source-level symbolic (C and Assembler) debugging without the need for expensive JTAG hardware debug tools.

The latest AMIDebug for UEFI release, developed specifically for the company’s flagship Aptio V UEFI Firmware, adds support for USB 3.0 debug among other important features. These newly-added features signify a key development in the evolution of this debug software, since many chipsets now only support USB 3.0 (XHCI) and in many cases no longer incorporate older USB standards (EHCI) in their hardware designs, such as the Intel(R) Atom(TM) x5-Z8300 series processors.

What remains unchanged in AMIDebug for UEFI is its ability to facilitate firmware development for AMI OEM and ODM customers in unprecedented ways thanks to its deep integration into the entire UEFI development ecosystem. AMIDebug for UEFI continues to offer standard debugging features like Break, Step, Step Over, Step Into, Step, run to cursor and set next statement, in addition to UEFI-specific debugging features like Stop at Driver Name Entry, Stop at PEIM Name Entry, Stop at CheckPoint, Stop at beginning of PEI/DXE, SMM Debugging and disassembly view. Moreover, many different firmware development viewers are supported including memory, CPU registers, PCI Bus, call stack, I/O and Indirect I/O.

Sigh, I wish these were available for UEFI ISVs and UEFI Security Researchers, not just restricted to AMI’s UEFI OEM/ODMs! I want one. 😦

More Information: