PCI "Generic" Option ROM Debugging with SeaBIOS, Coreboot and IDA Pro

In this post, I assume the PCI Option ROM is named TEST.ROM. Which is an option ROM not tied to particular hardware.  The debugging environment consists of two machines, either virtual or physical. In my particular setup, I used two physical machines. The debugging “host” runs Windows 7 64 with IDA Pro as a remote debugger. The “target (gdb server)” runs Linux—with Qemu as the “real” target of the debugging in the Linux machine. The sole reason to use Linux in the “target” is to enable rebuilding Coreboot and SeaBIOS which acts as the “container” of the target PCI option ROM. The steps to prepare the debugging environment as follows:

1. Configure and build SeaBIOS.
   1. Run make menuconfig in SeaBIOS root source directory. If you’re downloading SeaBIOS as Coreboot payload, it’s located at <coreboot_source_path>/payloads/external/SeaBIOS/seabios.
   2. Enable CONFIG_OPTIONROMS, CONFIG_PMM, CONFIG_COREBOOT_FLASH when you run make menuconfig.
   3. Configure debug level to 8 (CONFIG_DEBUG_LEVEL)
   4. Save your changes and quit from the configuration menu (make menuconfig).
   5. Build SeaBIOS by invoking make.
2. Configure and build Coreboot.
   1. Run make menuconfig in Coreboot root source directory.
   2. Disable both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN as either of these options will confuse the virtual machine (Qemu) and possibly modify the contents of the PCI option ROM at runtime (debugging). Producing unwanted side effects.
   3. Configure SeaBIOS binary not as ordinary payload, but as an ELF payload. Configure CONFIG_PAYLOAD_FILE to point to the SeaBIOS ELF file, i.e. <seabios_source_path>/out/bios.bin.elf.
   4. Save your changes and quit from configuration menu (make menuconfig).
   5. Build Coreboot by invoking make.
3. Insert TEST.ROM as CBFS component to Coreboot ROM file. The following are the steps to insert the PCI option ROM (the steps could be scripted):
   1. Combine TEST.ROM as CBFS component to Coreboot ROM with this command (invoked from Coreboot source code root directory):

                  ./build/cbfstool build/coreboot.rom add <path_to_TEST_ROM> genroms/test.rom raw
                 

   2. Check whether everything is OK with this command:

                 ./build/cbfstool build/coreboot.rom print
                

4. Run Qemu utilizing the newly built Coreboot ROM file as its BIOS (configured to stop and wait for the GDB connection).

   qemu –m 128 –bios <path_to_coreboot_rom> -hda linux.img –net none –nographic –s –S 
   

   The –net none option disables gPXE option ROM from Qemu to load. The gPXE option ROM complicates the analysis a bit. Therefore, it’s better to get rid of it.
   NOTE: If Qemu gPXE option ROM is enabled (default), the TEST.ROM option ROM would always be loaded at C980h segment. If Qemu gPXE option ROM is disabled, the TEST.ROM option ROM would always be loaded at C900h segment.
5. Run IDA Pro and connect via GDB remote debugging.
   1. Configure IDA Pro debugger to run in x86 16-bit mode.
   2. Attach to the qemu machine via Debugger|Attach|Remote GDB Debugger menu. Configure the IP address of your virtual or physical target machine there (which runs Qemu) and set the debugger specific option to run 16-bit code.
   3. When stopped at reset vector (FFFF:FFF0), create your required memory regions (Debugger|Debugger Options…|Set Specific Options|Memory Map)
   4. Configure breakpoints as needed.
   5. Run (press F9) and debug.

That's it. Now you can debug the "generic" option ROM to your hearts content :-)

Desktop Management Interface (DMI) Access Interface

Well, I should make an article about this later because it doesn't make it to my first edition book. First, let me emphasize that we're looking at the DMI Access Interface from the BIOS execution context, not from within an OS context. The DMI v2.0 specification (www-pc.uni-regensburg.de/hardware/TECHDOK/BIOS_DMI_20.PDF) "vaguely" states that the interface to the DMI from the BIOS execution context as follows:

To prevent the proliferation of interfaces for accessing information embedded in the System BIOS, the Desktop Management BIOS Specification will follow the System Device Node model used by Plug and Play, and use Plug and Play BIOS functions to access DMI information. Plug and Play functions 50h-5Fh have been assigned to the DMI BIOS Interface.

Well, it's not immediately clear what does it mean by "Plug and Play functions 50h-5Fh". A closer look into the PnP BIOS spec v1.0A (www.osdever.net/documents/PNPBIOSSpecification-v1.0a.pdf) reveals the crux of the matter. When you read through the PnP BIOS spec v1.0A, what you will find in section 4.4 is a description to the PnP BIOS entry point. Furthermore, try to find function "number" higher than PnP function 43h and you're out of luck. Now, from the description in the DMI v2.0 spec snippet above it's now clear that the higher function "number" (above 43h) is relegated to another spec (presumably after the PnP BIOS spec was ratified). One of them is the DMI spec. PnP BIOS spec was published in 1994, while the DMI spec v2.0 was published in 1996. Therefore, accessing the DMI "services" in BIOS code (or ring-0 code in an OS) is carried-out via PnP BIOS interface at function 50h to 5Fh. It seems all of this past effort was part of the DMTF standardization (I'm not 100% sure).

License for the source code in the Low Cost Embedded x86 Teaching Tool article

I haven't had the time to update the copyright notice in the Low Cost Embedded x86 Teaching Tool. However, if you want to use it (and modify it) for your own purposes, you could do so under the Gnu Public License (GPL) version 2 which mandates you to relase your changes. Coreboot project have been using some part of it for their use under the GPL. I'm going to update the license notice in the article ASAP. Cheers.

IOMMU Specification from Intel and AMD

This is just a dump of the links to download AMD and Intel IOMMU specification. For those of you new to IOMMU, a good introductory is at http://en.wikipedia.org/wiki/IOMMU.

Now, the specs:

AMD specs: http://support.amd.com/us/Processor_TechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf and http://support.amd.com/us/Processor_TechDocs/48882.pdf

Intel spec: http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf

Just a note that Intel calls the IOMMU as Virtualization Technology for Directed IO (VT for Directed I/O).