IBM OpenPower Firmware Source Code Brief Analysis

First post this year ;-)

I'm taking a detour to other hardware architecture here, despite this blog is focused on x86/x86-64. As for why, it's because I was working with IBM Power 5 machine for more than a year and I found it interesting. I'm not going to talk about Power 5 here though because it's a closed system, in terms of firmware. I'm here to talk about Power 8 and its successor.

The Power 8 architecture is the first incarnation of OpenPower hardware architecture. Luckily, the firmware source code for this platform is freely available in Github: https://github.com/open-power.

Now, let's look at how we might read the code:

• The most interesting part is the Initial Program Loader (IPL) firmware: https://github.com/open-power/hostboot. This is basically the equivalent of UEFI Platform Init (PI) code, or the bulk of the BIOS code in the old days--excluding the runtime code, such as power management and SMI handlers.
• The next interesting part is skiboot: https://github.com/open-power/skiboot. This looks like the equivalent of the non-PI part of UEFI because it provides the interface that the OS can call at runtime to communicate with the platform firmware. I might be wrong tough, but all code I skimmed over indicates that.
• Last but not least is petitboot: https://github.com/open-power/petitboot. This is basically an analog of GRUB or Systemd bootloader in x86/x86-64 Linux.

The important thing that's missing from the OpenPower Github is the Baseboard Management Controller (BMC) source code. I'm not sure why IBM doesn't standardize that part as well or at least provide a reference implementation. Perhaps, it's because IBM wants to provide a point for differentiation among its partners. Also, if we think about it, the BMC code is probably the most vulnerable point should some one wants to attack an OpenPower environment because it usually provides a remote access to manage the server even before it finished booting.

I'll update this post once I've read the IPL code in more detailed manner. Hint: if you want to read it as well, try starting with the linker script (*.ld) file.

Base-board Management Controller (BMC) Firmware Security

The security of the BMC firmware is very important, as compromising it means unfettered remote access to the target machine. There has been research into this area in the not too distant past:

• Exploiting Hardware Management Subsystem, by Simon Clow.
• Reversing Firmware using Radare2, by Anton Kochkov.
• IPMI: Understanding Your Server's Remote Backdoor, by Anthony J. Bonkoski.

All of them are interesting in their own right. Perhaps, Bonkoski's one is the most comprehensive? I don't know. I haven't dig into all of the papers myself.

Anyway, one of the most interesting development in BMC is OpenBMC, see: https://github.com/facebook/openbmc and https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/. Is it going to grant you access to Facebook-class infrastructure (from afar) if you find a flaw in it? Well, I don't think so, as it must've been protected by giant "firewall" in front of it. But, doing a code review on OpenBMC for flaws certainly a good exercise.

As a side note, let's not forget about Fujitsu, one of the most "underrated" server producer on the market. As a parting gift, let's look at what Fujitsu has in store in its BMC:

Fujitsu integrated Remote Management Controller TCP/UDP ports

Gentle Introduction to Coreboot

I've just stumbled upon this series of articles by  Lennart Benschop about Coreboot. It's a very smooth introduction to Coreboot that explains Coreboot components from a high level view and proceed toward more specific parts of it. You can read it over here. Note that Coreboot specific stuff starts at "Column" no.4. Have a nice reading :-)

AMBA-PCIe Interoperability

The native bus in ARM systems, Advanced Microcontroller Bus Architecture (AMBA)
[see: http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture] has been interoperable with
PCI Express (PCIe) for several years now. These are related documentation that helps understanding
how it works:
1. Designing an AMBA-based SoC with a PCI Express Interface,
   link: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=fcb3ebb3b4537c401230b3f3cd71e7895b7c5518

2. Building a Bridge from PCI Express to AMBA 3 AXI On-Chip Bus,
   link: http://www.synopsys.com/dw/dwtb.php?a=pcie_tb_axi
 
3. This one is even more interesting: Implementing a PCI-Express AMBA interface controller on a Spartan6 FPGA,   link: http://publications.lib.chalmers.se/records/fulltext/176608/176608.pdf
 
This shows how far the layered design of PCIe could interoperate with AMBA bus from ARM.

(First-Party) DMA Malware Paper

This paper is really interesting: http://www.stewin.org/papers/dimvap15-stewin.pdf
---------------------------------------------------
Abstract (excerpt): ... Modern computers contain dedicated hardware such as network and graphics cards. Such devices implement independent execution environments but have direct memory access (DMA) to the host runtime memory. In this work we introduce DMA malware, i. e., malware executed on dedicated hardware to launch stealthy attacks against the host using DMA. DMA malware goes beyond the capability to control DMA hardware.

We implemented DAGGER, a keylogger that attacks Linux and Windows platforms. Our evaluation conrms that DMA malware can efficiently attack kernel structures even if memory address randomization is in place. DMA malware is stealthy to a point where the host cannot detect its presence. We evaluate and discuss possible countermeasures and the (in)effectiveness of hardware extensions such as input/output memory management units (IOMMU).
---------------------------------------------------

For me, the very interesting finding on the paper is the presence of ARCtangent Microcontroller which (acts as the DMA "engine". The vendor of this "vague" MCU is quite hard to come by on G$$gle search. It turns out that ARC International is a subsidiary of Synopsys now. These are the relevant links:

http://en.wikipedia.org/wiki/ARC_International

http://www.synopsys.com/dw/ipdir.php?ds=arc_mpu (I think the paper probably talks about this chip)

http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/ARCEM/Pages/default.aspx

PS: "First Party" DMA is also known as Bus Mastering

Thoughts on Memory Allocation in Firmware (Particularly BIOS/UEFI related)

Memory allocation in firmware is basically not the same as one we would find on applications running in an OS because it's an "OS-free" environment. Therefore, the the benefits of OS protection for "memory allocation gone wild" is virtually non-existent. This puts codes running as part of the firmware execution at more risk compared to code running inside an OS. I have yet to put more scrutiny on the TianoCore (UEFI) implementation for memory allocation functions. Probably, it's much better than those in legacy BIOS modules or other related firmware predating it.

I have particular notes on routines akin to C language malloc(), free() and circular buffer handling functions. Calls to malloc() function in firmware level code is usually quite safe because several malloc()  implementations that I read, implements a sort of rudimentary exception handling which would bail out one module execution if not enough space is found when code in the "requesting" module asks for heap memory. However, there are still lingering possible of error when the module lost a reference to allocated memory due to pointer reassignment. I have yet to see bad behaving code like this. But it seems, the assumption on the malloc() implementation is that these things never happened!

As for circular buffers, this kind of thing is in use mostly to talk to storage devices and other "block" devices which transfers quite large amount of bytes in "block"s. Circular buffer implementations could use contiguous memory space if the code that initialize it found one such an available area. However, it could also be implemented as circular linked-list of fragmented chunks which are not necessarily adjacent in the physical memory. This is where things get interesting. A logic bug in function calling the one of the circular buffer function could result to access in the wrong physical memory address. That could happen if a calling function assumes that the circular buffer is implemented as contiguous physical memory chunks instead of a linked memory chunks (not necessarily contiguous in physical memory addresses). In this case, the developer who code the function calling the circular buffer implementation should be blamed as he/she didn't foresee an impending chaos he/she created. Unfortunately, I have yet to see "exception handling" on firmware-level code dealing with such things.

Reversing Applications Running on DOS Extender

Some BIOS/Firmware-related utilities are running in DOS "extender" mode, i.e. 32-bit Flat Protected mode. Reversing this kind of executable is not quite as straight forward as other DOS programs. Some of them "bind" the DOS "extender" binary with the core application executable into one "integrated" executable. A further optimization that you might find is executable compression before "bind"ing the executable to the DOS "extender". How would you deal with this kind of binary? Well, to be honest. It's not quite easy, but I found these steps help:

1. Unbind the DOS "extender" from the "integrated" executable. For this, you can use the SUNSYS Bind Utility which is part of the DOS32A DOS extender. It's freely available at http://dos32a.narechk.net/index_en.html. Using the SUNSYS Bind utility, you can obtain the real executable. Usually in the form of LE executable. 
2. (This step is optional, depending on the condition of the "unbound" executable). If the LE executable is compressed with UPX, you can use the UPX utility to decompress the executable to obtain the real executable. The UPX utility supports decompressing executables packed with UPX, with the -d command.

After the step(s) above, everything is business as usual for the reversing ;-). This trick is probably handy in some situations. Anyway, if you need to boot to DOS to run DOS32A utility, you can use an empty flashdisk and boot to DOS (or Windows 98) from it. The HP USB Disk Storage Format Tool is handy on this situation.