Arium, ASSET InterTech, and Intel IE

Though I’ve discussed some Intel UEFI debugging so far:
I’ve not mentioned Arium’s debugger yet. The Intel Tunnel Mountain UEFI dev board can be used with the Intel UDK Debugger Tool, a 2-system debugging solution that uses Windbg on Windows, GDB on Linux. If you want to trace into silicon, you need to buy some debugging hardware, and a debugger that works with that hardware. One solution is to use Arium’s ITP widget and their debugger. It is EXPENSIVE, so you have to be well-funded to have one of these units, but I’ve heard it is powerful. They have products for ARM and Intel.

ASSET InterTech acquired Arium a while ago, though I still think of them as Arium. 😦

The other week at Intel IDF, Intel announced the Innovation Engine (Intel IE), but no details yet, except for this blog post:

ASSET just blogged about updating their product to support Intel IE, excerpt here:

At this past Intel Developers Forum (IDF) in San Francisco, Intel unveiled some preliminary information on the new Innovation Engine (IE). In a nutshell, the IE is an embedded processor which allows system builders and their partners to build unique, differentiating firmware for server, storage, and networking markets. Differentiation has always been, and always will be, a key challenge for OEMs in the Intel space. Hardware, in and of itself, is very common across platforms designed with Intel silicon. There can be some differentiation based upon using some custom Intel SKUs (if you are a large enough customer), or designing circuit boards which deviate from the platform design guideline recommendations, but these come at a high cost – either in terms of Bill of Materials (BOM) cost, or risk of having a product with lower overall operating margins. Competitive advantage on Intel designs often comes from the embedded firmware, either the BIOS or the Baseboard Management Controller (BMC) code. And in the server world, OEMs are often beholden to the UEFI vendors for customization. So OEMs often invest in customization of system management to create differentiation – which is where the IE comes in. The IE can supplement or replace much of the functionality that may exist on today’s BMCs. In addition, for lower-end systems that may not require BMCs, the IE can provide a platform which delivers system management capabilities at no extra BOM cost. In Intel’s words, “some possible uses include hosting lightweight manageability features in order to reduce overall system cost, improving server performance by offloading BIOS and BMC routines, or augmenting the Intel® Management Engine for such things as telemetry and trusted boot.”

I’m waiting for Intel to release real information on their Innovation Engine.

Read the full ASSET blog post here, to see how they are using Intel IE with their diagnostic products:

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: