The BIOS Blog

Welcome to the dark corner of BIOS reverse engineering, code injection and various modification techniques only deemed by those immensely curious about BIOS

Monday, January 30, 2017

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

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:

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

  • The most interesting part is the Initial Program Loader (IPL) firmware: 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: 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: 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.

Monday, December 12, 2016

BIOS Disassembly Ninjutsu Uncovered on Play Store

Somebody has just put BIOS Disassembly Ninjutsu Uncovered "scanlation" on Play Store. Well, it's not really manga "scanlation" quality. But, I'm rather surprised someone put the effort to do that: You might want to give it a try. 

In my opinion, the PDF version in github is much more readable. Perhaps, I should make it available on Play Store, or is there anyone want to volunteer to do that? Cheers.

Thursday, September 22, 2016

Down to Silicon Level Debugging

First off, I'm not a "forward" BIOS/UEFI engineer. At least not one who worked officially in a BIOS/UEFI software development company or motherboard company. I did got an official access to AMIBIOS Core8 source code and tools back then under NDA for one of my clients to customize it for a custom x86 motherboard. But, that's as far as I got into the game. This is relevant to this post as I don't know exactly the process of silicon level firmware development validation. The farthest I went was a sort of "Serial ICE" with Coreboot and also debugging via Power-On Self Test (POST) code passed over serial port in AMIBIOS Core8. That was it. I didn't even manage to do debugging via PCI POST card, but I presume it would be similar to its "redirected" cousin in the serial port. There is another way to do firmware debugging, via JTAG pins, and by using In-Circuit Emulator (ICE). Despite having been an Electrical Engineering student, I'm not yet familiar with those territories. But, AFAIK both are as good as if not more powerful firmware debugging technique compared to using Serial ICE or POST card.

Let's focus on the ICE part. There was at least one mistake I did in my BIOS book that I didn't realize due to my handicap in not having an ICE and its related skills. You can see it in the quoted errata below (it's also in the addendum part of my book over at github):

The address aliasing mentioned in Chapter 4 section 4.1.1 page 4 (the paging messed-up in the PDF) should cover both E-segment and F-Segment (E_0000h-F_FFFFh), not just the last 64-KB segment. Somebody used a sort of CPU logic analyzer to confirm this fact.
The guy who tipped me over about this was using an expensive ICE to validate the fact above. I'm not exactly sure how he tapped all of the "wires" on the chipsets and the CPU itself, but very probably similar in principle to what "Bunnie" did to the first XBox version (see: IIRC, the was using one of Arium ICE products. Arium was acquired by another company, see: However, their ICE products live on as (very probably) the ScanWorks and SourcePoint line of products from asset-intertech. These ICE products used to cost north of $20k a piece back then. I don't know about it at the moment though. With an ICE, you essentially put the CPU in a "hard" debug mode, where you can freeze it in a way ordinary debugger cannot because there is no OS or firmware required for that to happen.

Anyway, I was quite surprised to find a "low cost" version of this kind of ICE over at: Well, I'd like to thank to whoever posted a comment about this ICE in my previous post. It's very interesting nonetheless ;-).

Anyway, for the uninitiated, a (not so) useful background is at