(Rather Late) Surprise: Intel has "PCI Expansion ROM OS" Implementation for Computer Cluster

For some reason I stumbled upon one of Intel's patent application: Cluster computing - nic based os provision WO 2012040606 A2. The patent application cited my BUILDING A ''KERNEL'' IN PCI EXPANSION ROM article as non-patent citation.

I had that thought back then, that some companies must've built (or will build) something usable out of the principle explained there. I'm actually rather surprised why it didn't happen earlier. Of course, we have etherboot and PXE-boot eons ago. However, there's no such complete OS, even though a very small one in PCI Expansion ROM. Well, perhaps one of the limitation is the cost of the ROM.

Anyway, the use case explained in the patent application is interesting nonetheless. Head over to the patent application to see more details. It's a good read ;)

Experimental PCI Expansion ROM "OS" Code Migrated to GitHub

The code for the experimental PCI Expansion ROM "OS" explained in the Building a "Kernel" in PCI Expansion ROM article is now in GitHub: https://github.com/pinczakko/PCI-Expansion-ROM-OS. I made some changes to make it compile-able in current version of Nasm and GCC. I've only tested the compilation in Arch Linux (x86-64). I'm not sure it will work in other Linux distros. Give it a try ;-). Quick skim over the resulting binary seems to indicate the result is OK. I'm going to check it with a disassembler later on. If anyone wants to help me with that, please do so and post your result in the comment section below. 

Many of you might be aware that the code has been modified into pure GCC-only code in the Low Cost Embedded x86 Teaching Tool article. I need to migrate that code as well. But, I'm quite sure it will require special GCC version to be able to emit the correct binary, akin to the one used by Coreboot. I'll post an update once I've updated that one as well. 

Anyway, it's rather surprising to me that using Nasm + GCC is more future-proof compared to using GCC alone. It shows that you can't be really sure about the future-proof-ness of the toolset you used for software development.

(Cross) Compiling My Sample PCI Expansion ROM Code

My sample PCI Expansion ROM code over at Low Cost Embedded x86 Teaching Tool is no longer compile-able on recent x64 Linux distributions. This is due to the fact that the default GCC toolchain in those Linux distros doesn't support output in the form of the particular ELF32 i386 required by the source code. Other possible problem is the GCC toolchain doesn't support 16-bit code output anymore, as required by the linker script.

For trouble free source code compilation, you're advised to download and build Coreboot cross compiler, see: http://www.coreboot.org/Build_HOWTO#Known_issues. Just invoke:

make crossgcc

in the directory where you download Coreboot (Coreboot root directory) to build the cross compiler. You'll also need to alter the Makefile of the PCI Expansion ROM code to use the newly built cross compiler. The toolchain components that you need to change in the Makefile is pretty much everyone of them, i.e: CC, LD, AS and OBJCOPY. The cross compiler should be located in the /util/crossgcc/xgcc/bin directory, once you have completed building the cross compiler. If you are still unsure about the path of the cross compiler toolchain, open the .xcompile file in Coreboot root directory.

NSA BIOS Backdoor Article Part 2: BULLDOZER is up

You can read the complete article at: NSA Backdoor Part 2, BULLDOZER: And, Learn How to DIY a NSA Hardware Implant

This is the excerpt:
This article is the second part of a series on NSA BIOS Backdoor internals. This part focuses on BULLDOZER, a hardware implant acting as malware dropper and wireless communication “hub” for NSA covert operations.

NSA BIOS Backdoor Article Part 1

OK. This is part one of my controversial article series of the year :P

NSA BIOS Backdoor a.k.a. God Mode Malware Part 1: DEITYBOUNCE
This first part focuses on the DEITYBOUNCE malware described in the NSA ANT Server document.
I won't spoil the details here. Head to the link above for the details :-).

UEFI EDK II on ARM (BeagleBoard) and My Next Article

I haven't been checking out TianoCore for a while and when I did, I stumbled upon this: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPkg. It's an interesting proposition for UEFI-on-ARM research and the likes. 

As for the next article, I'm still looking for a suitable EFI Option ROM to work with. My previous candidates didn't live-up to expectation as they were quite unworkable given the free time I have to work on the article. 

Stay tuned.

Malicious Code Execution in PCI Expansion ROM Article

The "Malicious Code Execution in PCI Expansion ROM" article is up. You could read it over at: http://resources.infosecinstitute.com/pci-expansion-rom/.

It's a mix of old and new things; from what we have known from the old PCI expansion ROM as mentioned in PCI specification and new "feature" added by the PCI firmware spec.

PCI Expansion ROM Execution Environment Peculiarity

This post is related to the x86 Segment Descriptor Cache stuff I posted a while ago. In my previous book, this fact is not included. So, what's the weird thing about the PCI Expansion ROM execution environment? Well, it runs in "big-real mode"/unreal mode. It may not sound obvious but this is the excerpt from a related specification:

"When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing."

 To put things in perspective, I plan to just combine it with the upcoming POST Memory Manager article on my website. I haven't had enough time to finish that one.

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 :-)