(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 ;)

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: https://play.google.com/store/apps/details?id=com.appjik.book.bios. 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.

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: http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html). IIRC, the was using one of Arium ICE products. Arium was acquired by another company, see: http://www.asset-intertech.com. 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: http://www.loper-os.org/?p=1667. 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 https://en.wikipedia.org/wiki/In-circuit_emulation

Moving Winflashrom code to Github

I ported Coreboot (formerly LinuxBIOS) flashrom utility to Windows a long time ago as my activity in Google Summer of Code and named it winflashrom. Because code.google.com will be shutdown this year, I moved the code to github: https://github.com/pinczakko/winflashrom.

This is old news because the code haven't been updated for years. However, it might still relevant for those who want to port flashrom or other similar utility to present day Windows. I haven't developed Windows driver anymore since Windows Server 2003. I'm not even sure if WDM-style driver is still in use in Windows. But, I might be returning to develop Windows driver this year. So, yeah, you (and I) never know.

Looking into The State of Firmware Security in Russia

I think every major industrialized country has its own policies in preventing malicious IT equipment and products to enter their premises, let alone being used within the country. In this post, we will look into one of Russian computer hardware maker, Kraftway (http://www.kraftway.ru/en/). This company might be a bit obscure to you. But, I think it serves quite a big chunk of the Russian and possibly CIS market. It was even visited by Dmitry Medvedev when he was still President.
This company is interesting for two things:

• It is not just a "box" mover. It tailors the machines it made to meet the customer requirements. Among its in-house expertise is custom firmware, including UEFI firmware. If you look at this page: http://www.kraftway.ru/en/products-and-solutions/, at the end of it, you can see that it has in-house expertise to work on UEFI security modules and Trusted BIOS (whatever that might imply). Another thing that catches my attention is this: 

In 2010 the company signed an agreement with a telecom giant Cisco establishing a special procedure for the certification of Cisco products in Obninsk manufacturing facilities. Kraftway ensures that Cisco products comply with the requirement of the Federal Technical and Export Control Service on information security. Such certified products can be used in systems processing sensitive or confidential information. In 2012 Kraftway launched the production of Fujitsu PCs with a trusted BIOS and all-in-one PCs based on the Russian processor Elbrus.

I'm not so sure what does the statement meant by "requirements". Perhaps, it includes firmware-level compliance of some sort. You can look at the whole thing over here. 

• The second thing is Kraftway also made PC based on the Russian homegrown Elbrus CPU (http://www.kraftway.ru/en/about/milestones/). Of course, in the process, it creates the firmware alongside experts from MCST. The premise for using Elbrus CPU is national security needs and "sensitive" computing needs. So, it's understandable. 

Well, I recall that Dell also did the very same thing as Kraftway with respect to firmware and hardware customization. Dell puts crypto-stuff in the firmware even before UEFI hits the market for some of its server product. Perhaps, that's not meant to be used by the masses, only certain customers.

Anyway, scrutinizing the firmware code or creating a custom ones is highly logical for "sensitive" (high-security) computing gear. Every major developed country do that. IIRC, Germany has its own Coreboot Laptop for that kind of purpose. Even China and Taiwan is doing that as well, albeit I haven't yet found writings on that.

The State of My Firmware Research

Well, I decided to post this because I've been over-promising and under-delivering for several years now.

Straight to the matter, I've been leaving my firmware research work in a state of hibernation for almost a year now due to a (some?)  product development work I'm still working on as of now (which I cannot elaborate further). It's not that I feel firmware is not interesting anymore. On the contrary, I feel it's far more interesting now than it used to be due to the raise of connected embedded systems (now re-badged as Internet of Things a.k.a "rather intelligent" data collection systems). The main problem for me is finding time to work on this research again as it's unfortunately not my day job.

As for my work on the continuation of my BIOS Disassembly book project. I will try to find time for that, but I don't want to over-promise on it. Hopefully this clears things up. 

How Boot Firmware Development and Driver Development Differs--PCI Bus Implementation Case Study

This post is not BIOS/UEFI specific per-se. However, it has a very close relation to it because it delves deep into Windows device driver architecture.

Most of BIOS/UEFI modules are aware of the CPU architecture, motherboard chipset and all supporting logic in which it runs. However, the same assumption cannot be made for an OS, such as Windows. Therefore, BIOS/UEFI modules mostly can take for granted the CPU and bus architecture in which it will run. The same is not true for a device driver. For example, a PCI or PCIe explansion card can be used in the same operating system but runs on entirely different CPU architecture. This means device driver creator couldn't and shouldn't assume the CPU architecture and bus architecture in which it will eventually run.

This series of posts by Windows PnP subsystem developer is very enlightening in this respect:
http://blogs.msdn.com/b/doronh/archive/2010/05/05/arbitration-and-translation-part-1.aspx
http://blogs.msdn.com/b/doronh/archive/2010/05/06/translation-and-windows.aspx
http://blogs.msdn.com/b/doronh/archive/2010/05/06/arbitration-and-translation-part-3.aspx

This hopefully shed some light in system software developments :)

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

PDF of My Past Articles on Infosecinstitute

You can download the PDF version of my past articles on Infosecinstitute via these links:
https://sites.google.com/site/pinczakko/bios-articles
and
https://sites.google.com/site/pinczakko/miscellaneus

Future articles will be available as PDF as the embargo lifts up.

x86/x64 CMOV Instruction vs ARM Conditional Instruction Execution

If you've been programming in x86/x64 assembler for a while now, you'll know the CMOV (Conditional Move) instruction. This instruction was introduced in P6 (Pentium Pro) for compiler optimization.

It seems that the conditional instruction execution in ARM (32-bit only?) predates the P6 CMOV instruction debut. Conditional instruction execution of course speeds up comparison statements in many occasions in our code. 

Now, did Intel "copied" the technique from the RISC world and applied it to x86 back then? 

IIRC, P6 (Pentium Pro) was the first Out-Of-Order CPU core from Intel. I recall that this architecture was more RISC-like on the inside.

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.

Gizmo Board (AMD G-series APU)

Has anyone play with this thing: http://www.gizmosphere.org/why-gizmo/ ? It's very interesting because it uses Coreboot out of the box instead of Legacy-BIOS/UEFI. Well, I'm not sure whether it's possible to use UEFI as it's payload or not (Coreboot support UEFI as its payload).

But from embedded development point of view, just boot straight to Linux from Coreboot ;-). Linux drivers will take care of the rest of system initialization. The interesting thing is, the kit also provides an "explansion" board to tap into the I/O of the x64 system (the AMD G-Series APU), well, I exagerrated a bit, I meant you could hook directly to the I/O which very probably connects to the "southbridge" of the entire system.

Anyway, from pure raw performance point-of-view, this is a real raw power  monster to play with. But, I'm not sure how it compares to BeagleBoard when playing with signal processing. But surely for computer vision stuff, it's certainly very powerful given that OpenCV is tuned for x86 (x64?) architecture by default.

I think it's also an interesting platform to play with Coreboot and to understand the inner working of modern day x86/x64 processor.

Above and Below vs Greater and Less in x86/x64 Architecture

There are two different "families" of integer comparison in x86 assembly language. The first one revolves around the "above" and "below" moniker, and the other one revolves around the "greater" and "less" moniker. It's not very clear what the difference between both "families" of instruction until you take into account signed and unsigned integer comparison. The "above" and "below" family of integer comparison instructions deal with unsigned integer comparison. You could verify this by looking at Intel x86/x64 manual. In the manual, you would find that the "above" and "below" instruction family only check for carry flag (CF) but not the sign flag. Let's see a copy of the instructions explanation from Intel manual:

JA rel8  -- Jump short if above (CF=0 and ZF=0).
JAE rel8 -- Jump short if above or equal(CF=0).
JB rel8 -- Jump short if below (CF=1).
JBE rel8 -- Jump short if below or equal(CF=1 or ZF=1).

As you can see, there's no check for sign flag in the instructions above. Therefore, they are all unsigned comparison. Now, let's have a look to the other family, the "greater" and "less". Again, let's see a copy of the instructions explanation from Intel x86/x64 manual:

JG rel8 -- Jump short if greater (ZF=0 and SF=OF).
JGE rel8 -- Jump short if greater or equal (SF=OF).
JL rel8 -- Jump short if less (SF‚ OF).
JLE rel8 A -- Jump short if less or equal (ZF=1 or SF‚ OF).

As you can see, all of the "greater" and "less" comparison checks against the sign flag (SF). Therefore, they're all signed integer comparison. The difference between the two "families" of instruction could be easily overlooked by those new to x86/x64 assembly language. I hope this post clarify that.

Thoughts on Having Access to Official BIOS Source Code

I have access to official AMI BIOS Core8 source code for more than a year now,
due to one of my work. I think it's good to share the ups and downs of having access to such source code. 

It's nice to have BIOS source code at your hand because you can do a lot of things.
However, having access to the source code doesn't equal understanding the code any better. 
It's quite a steep learning curve to understand how to use the development tools and 
also some code requires you to understand various hardware protocol to have a sense on it. 


Of course, having reversed some BIOS binaries helped me. But, it also produces unwanted effects.
Sometimes, I tend to use "binary surgical" approach instead of trying to use the existing development tools, 
which in the end produces ugly kludge. It takes sometime for me to get used to the development tools.
Overall, though I can say that I learned a lot from the source code.

Tweeting New Articles

I'm starting to tweet link to articles I'm writing. I've been too busy lately. Probably that should be enough for sometime. You could follow the update over at twitter @Pinczakko. Of course, this blog will still be more in-depth.

Implanting malicious hardware

After reading this and this over at Bunnie's blog, I came to think that how easy someone can "implant" malicious hardware anywhere in the supply chain before the hardware reaches it's destination. Ball Grid Array chips are complex beast to work with physically. But, with the BGA reballing tool, even a complex chip like that could be replaced with ease (quote from Bunnie's blog):

Before seeing this, I was under the impression that reballing was an involved process, but with this jig the operator could strip and reball a chip in under a few minutes, which translates to a labor cost of a couple dozen cents

This is insane. In PC motherboard, the chipset is mostly in BGA packaging. Flash ROM chips these days are back in the old "DIP" (Dual In-line Package), so it's quite easy to work with. But, to think that even BGA chips could be altered with ease is just mind boggling.

x86 Segment Descriptor Cache

BIOS-related code "abuse" the x86 segment descriptor cache for its own pusposes. Therefore, it pays to know the details of the x86 segment descriptor cache. Aside from information in section "3.4.3 Segment Registers" of the official Intel Software Developer Manual Volume 3A and 3B, this link: http://www.rcollins.org/ddj/Aug98/Aug98.html is also very useful and gives historical insight into this widely "abused" feature that Intel have to support due to its wide usage back to the i386 era.

"Frying" Another USB-to-IDE Converter

Last wednesday was the second time I fried another USB-to-IDE converter device due to buggy ATA command that was sent to the IDE device (a DVD-ROM Drive). I'm not really sure which command that causes it to happen. But, now is the time to look into ATA command set much deeper. Well, this is just a precaution for guys/girls out there working with *-to-IDE converter device. Be very careful with ATA command that you send to the IDE device. Apparently, the problem was the "offending" ATA command corrupt the firmware inside the converter. I haven't look very detailed into what type of chip used in the converter. Probably MIPS-based or ARM-based microcontroller. Too bad I don't have JTAG debugger to see what exactly happens.

Facebook Comment Feature Now Available

Hi guys, Facebook commenting is now enabled in this blog. I hope this enables better communication with the blog audience. Another news is that I'm going to do cross-referencing to Pinczakko Official Website from here. I'm back to writing articles now that it has been several years dormant. The last article I wrote was on the DLL support in Award BIOS. Well, it has been a long time ago.

How to Read The ACPI Specification

The ACPI specification is a huge documentation. Especially ACPI v4.0 spec. It's 727 pages. The how to read it? It depends. For now, I'd like to focus from the perspective of someone who read ASL (ACPI Source Language) source code. Reading ASL code is particularly rather frustrating for beginners. Here's how to do it:

1. If you're total newbie to ACPI, read Chapter 1. Otherwise, proceed to step 2.
2. Read Chapter 4 - ACPI Hardware Specification briefly.
3. Read Chapter 5 - ACPI Software Programming Model briefly.
4. Read Chapter 18 - ACPI Source Language Reference briefly.

Now, go back to the ASL source code that you want to understand and look-up the meaning of the operators in Chapter 18 - ACPI Source Language Reference. Sometimes, you have to repeat this several times to get used to the operator. Now, let's see an example:

// Define a Lid switch
OperationRegion(\PHO, SystemIO, 0x201, 0x1)
       Field(\PHO, ByteAcc, NoLock, Preserve) {
          LPOL, 1 // Lid polarity control bit
       }

Device(\_SB.LID){
       Name(_HID, EISAID(“PNP0C0D”))
       Method(_LID){Return(LPOL)}
       Name(_PRW, Package(2){
          1, // bit 1 of GPE to enable Lid wakeup
          0x04} // can wakeup from S4 state
       )
}

Scope(\_GPE){ // Root level event handlers
       Method(_L01){ // uses bit 1 of GP0_STS register
          Not(LPOL, LPOL) // Flip the lid polarity bit
          Notify(LID, 0x80) // Notify OS of event
     }
}

In the code above, the words: OperationRegion, Method, Scope, Name, and Field are ASL "operators". Therefore, to know what these operators do, look at the ASL Operator Reference in Chapter 18 (section 18.5) in ACPI specification revision 4.0. There are more things left to be explained to understand the ASL source code above. I'll leave for another time. The most important thing is: now we can read the ACPI specification much more efficiently. Cheers :)