Parsing Option ROM Firmware

A few weeks ago an issue was opened on fwupd by pippin. He was basically asking for a command to return all the hashes of the firmwares installed on his hardware, which I initially didn’t really see the point of doing. However, after doing a few hours research about all the malware that can hide in VBIOS for graphics cards, option ROM in network cards, and keyboard matrix EC processors I was suitably worried also. I figured fixing the issue was a good idea. Of course, malware could perhaps hide itself (i.e. hiding in an unused padding segment and masking itself out on read) but this at least raises the bar from a security audit point of view, and is somewhat easier than opening the case and attaching a SPI programmer to the chip itself.

Fast forward a few nights. We can now verify ATI, NVIDIA, INTEL and ColorHug firmware. I’ve not got any other hardware with ROM that I can read from userspace, so this is where I need your help. I need willing volunteers to compile fwupd from git master (or rebuild my srpm) and then run:

cd fwupd/src
find /sys/devices -name rom -exec sudo ./fwupdmgr dump-rom {} \;

All being well you should see something like this:

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/rom -> f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57 [Version:]

If you see something just that, you’re not super helpful to me. If you see Error reading from file: Input/output error then you’re also not so helpful as the kernel module for your hardware is exporting a rom file and not hooking up the read vfuncs. If you get an error like Failed to detect firmware header [8950] or Firmware version extractor not known then you’ve just become interesting. If that’s you, can you send the rom file to as an attachment along with any details you know about the hardware. Thanks!


Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

15 thoughts on “Parsing Option ROM Firmware”

  1. I have a problem with current git master. On F22 I configured fwupd with –enable-colorhug=no (don’t have it, and I doubt you are of any interest in results from it). Then make gave me “fu-provider-usb.c:26:18: fatal error: gusb.h: No such file or directory”. Obviously I checked for presence of libgusb-devel: pkg-config gusb –modversion is 0.2.5, so it’s not the problem.

      1. You’re welcome.

        Checked, it builds now. But apparently there are nothing interesting in my notebook: one rom with checksum and version, and two ‘Error reading from file: Input/output error’ lines.

      2. Also, I remembered that ./configure do not detect properly absence of the docbook2X (failure in make on docbook2man), probably worth to check it too.

  2. Doing the ./, install a package, repeat dance on F22. Had to disable colorhug and now I am stuck during make with a missing gusb.h

    Is F22 too old to satisfy the dependencies?

  3. I have only following:
    Failed to connect to fwupd: Error calling StartServiceByName for org.freedesktop.fwupd: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.fwupd timed out
    Failed to connect to fwupd: Error calling StartServiceByName for org.freedesktop.fwupd: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.fwupd timed out
    Failed to connect to fwupd: Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was reached

    Starting service fwupd by systemctl start didn’t change anything. What’s wrong?

    1. You don’t need to run fwupd itself, you only need to run the fwupdmgr which should run daemonless. If you do want to work it out, try running /usr/libexec/fwupd –verbose on the command line as root.

      1. I probably haven’t explained it properly. If I understand correctly, running command you’ve provided:
        find /sys/devices -name rom -exec sudo ./fwupdmgr dump-rom {} \;
        should print something like this
        /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/rom -> f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57 [Version:] to stdout. Am I right? But it’s printing only mentioned timeouts :/


  4. I have an Intel GPU which exposes a ROM and i915 reads it OK afaik, otherwise the module load would have spewed a warning. However, when reading it via sysfs, EIO is thrown which is weird given that pci_read_rom() uses the same pci_map_rom() that i915 does. I’ll have to dig deeper.

  5. This code in looks like an incompletely-fixed copypaste:

    # UEFI support
    AC_ARG_ENABLE(uefi, AS_HELP_STRING([–enable-uefi],[Enable UEFI support]),
    enable_uefi=$enableval, enable_uefi=yes)
    if test x$enable_uefi != xno; then
    AC_DEFINE(HAVE_UEFI,1,[Use ColorHug support])
    AM_CONDITIONAL(HAVE_UEFI, test x$enable_uefi = xyes)

    I don’t know which software I need to make this pass. Or does it check for an already-installed copy of fwupd?

Comments are closed.