Thursday, January 12, 2017

Whose bug is it?

My favorite quote from chapter 1, page 1 of includes "'If you can fix a hardware bug in firmware, it’s not a bug but a documentation issue.'  —An anonymous hardware manager." I still recall being aghast upon hearing that utterance early in my career, but over time I grew to understand the wisdom. In fact, this inaugural chapter from 2015 book further elaborates on work-around's of hardware concerns that can be implemented in firmware.

This same sentiment was echoed in the position paper and presentation for the 2010 IEEE International High-Level Design Validation and Test Workshop. Specifically, the firmware can be modified at the 23rd hour to fix a work-around in hardware, leading to a potentially long list of 'firmware changes' during a product's postmortem. This sentiment is expressed in 'Incentives to fix issues in firmware cause root cause to be commonly incorrectly assigned to firmware' of the presentation and the following section of the paper:

      "There could be confusion between the root cause and the fix
      for issues. In particular, there is great pressure to resolve
      hardware issues in firmware due to the order-of-magnitudes
      difference in the cost of resolution. A “spin” of a chip may
      take many weeks and cost millions of dollars whereas a
      firmware fix may cost a few thousand dollars and a day or two
      of total work. In fact, many modern chips are designed so the
      firmware can configure the chips to work around issues in the
      field rather than having the hardware recalled. The public is
      simply told that there is a firmware issue when, in fact, the
      firmware resolved what was a hardware issue. "

I also recall being given a harried call on a Friday night about a the number of 'firmware bugs' on a product. I replied to the caller with some of the sentiments above, including the caveat 'I think that we can get the firmware update out by Monday, but I don't believe we can get a new stepping of the SOC by then.' Regrettably programs don't roll up the reason for the firmware changes and people are just shocked by the cardinality.

And often these bugs are not easy to find Bohrbugs, but Heisenbugs or Hindenbugs where there is a subtle interaction between host firmware and opaque hardware state machines. A week of investigation may yield a solution wherein one line of code changing one bit in a register access yields a solution. A few months ago a firmware manager at a conference related to me that the promotion process in his company entailed upper management reviewing the Git commits of the engineers. The firmware manager had to defend the smaller number of code changes versus the OS kernel guys as each delivering similar business value. But I still recall the final quote from the manager when he smiled and said 'The coolest part is that they are reviewing code changes, right?'

Sometimes these work-around's mitigate errata in the hardware (board, silicon, etc), and sometimes the changes are for cost savings. An example of the latter I recall includes a board design where the integrated Super I/O could be decoded as I/O addresses 0x2E/0x2F or 0x4E/0x4F by application of a pull-down or pull-up resistor, respectively. The hardware design engineer omitted the resistor in order to save costs on the Bill of Materials (BOM), so the boot firmware had to probe for what port value being decoded on each machine restart. And this was a cost savings of a single surface mount resistor.

The above discourse isn't meant to be an apologist view about firmware bugs, though. In general there are many bugs based upon programming flaws, not just hardware work-around's. If one is interested in the latter, take a look at But hopefully this posting will provide an alternate view into firmware and firmware changes.

Sunday, January 1, 2017

Saying good bye to 2016

I meant to do a final blog of '16 but I instead opted to catch the fireworks at the Seattle Space Needle

I like the end of the year as it hosts the Chaos Communications Conference (33c3). I recall seeing Trammell Hudson's Thunderstrike 2 over the '15 holiday, and for this '16 holiday I watched his talk on Heads, variously described in

I like Trammell's threat model write up at, too. Today we only have the higher level

It was interesting to see his mention of Intel (R) FSP and also reference our work on pre-OS DMA protection

Another talk of interest for the pre-OS was the review of porting UEFI Secure Boot for virtual machines This entails the Open Virtual Machine Format (OVMF) variant of EDKII that executes upon QEMU and is used as the guest firmware in projects like KVM, Virtualbox, etc.

The latter talk included a reference to the EDKII lock box
work and emulating the full System Management Mode (SMM) infrastructure. The addition of more of the SMM infrastructure in was positively mentioned, too.

Speaking of security and 33c3, an interesting read about researchers and industry was posted to As long as the flaws are responsibly disclosed such that the conference presentations aren't zero-day events, I cannot argue with their sentiment.

One common element discussed in Heads and the Virtual Secure Boot topics entailed availability of full platforms. In that area there is great progress in having a set of full EDKII platform code in source that works with an Intel(R) FSP for the embedded Apollo Lake (APL) SOC (formerly known as "Broxton") in the repository

Regarding security and treatment of EDKII issues, we have moved our advisory update to gitbook from the former two PDF postings These recent postings represent fixes that honored the industry request for six month embargo of the project updates. Going forward we'd like to auto-generate the advisory from Bugzilla, but for now the document is manually curated. There have also been discussions of moving from the advisory document issue enumeration to things like CVE's which is an investigation in progress, too.

Moving into 2017, maybe I'll catch up to George Westinghouse's number of issued US Patents. I left 2016 with 354 issued, whereas George has 361

2017 should also feature an update to a couple of UEFI books, including Beyond BIOS and Harnessing the UEFI Shell Beyond BIOS was originally published in 2006, so this update will mark over a decade since its first appearance.

It has been an interesting run on this project, with over 17 years on the EFI team and nearly 20 years at Intel. I look forward to what the next wave of technology will bring in '17 and beyond.