How To Debug A Bios

[Krash]

I am looking at replacing my bios in VMware. I have a bios that loads to a bootloader but it only works for windows XP.

I am in general wanting to debug the Bios and see what the problem is. I have tried with GDB remote debugging and IDA(using GDB remote) The problem that I am seeing is that while I am debugging all the instructions are 0. Maybe I am using GDB incorrectly, It seems to not be the best thing for 16 bit debugging though.

I know assembly and C so programming isn't a large hurdle for me. I just want to be able to see what my code is doing and why it's failing.

How can I cleanly debug a Bios?


I am open to recommendations or advise apart from "Don't do this." I want to learn this and I have a goal and I want to make this happen.

[iansjack]

A BIOS that only works for XP? How does the BIOS know what OS is or isn't installed?

[Octocontrabass]

I am looking at replacing my bios in VMware.

Why?

[Schol-R-LEA]

I am reading this to mean that the BIOS image file that comes with your copy of VMware (to be used by, and run on, the virtualized CPUs - though I think you can also configure it to use the system's native BIOS instead) runs correctly when VMware itself is running under XP, but not when VMware is running under, say, Windows 10. Is this what you meant?

If so, then my question is: are you comparing behavior on a 32-bit version of XP to that running on some 64-bit version of Windows? Also, is the version of VMware the same on both, or two different versions, and if they are the same, is it a 32-bit version or a 64-bit version?

Some information on how the two installations of VMware are configured, both in general and for the boot loader you are testing, might clarify things as well.

What I am thinking is that the problem is in the emulation of real mode operations on a system running in long mode. But I really would need to more details to say if that's the case or not.

Conversely, for the machine it is failing on (if it is two different ones), have you checked to make sure virtualization is in fact enabled in the motherboard's boot-time system configuration? It sounds like a no-brainer, but you'd be surprised how easy it is to forget the basic things like that, or change it unintentionally when you are trying to set up something else.

Also, have you tried testing the boot loader using a different virtualizer (such as running it in Hyper-V using the guest OS client, or probably more practically, something like VirtualBox, or QEMU for Windows), or an emulator such as Bochs?

In any case, as I said, I am pretty sure that you can configure VMware to use the motherboard's own BIOS rather than the image file that is provided with the program (which is designed to a 'generic' sample BIOS meant to reduce the chances of any unintended BIOS dependencies during development). I will see if I can find out more about that for you, again, assuming I understood your problem correctly.

[Krash]

A BIOS that only works for XP? How does the BIOS know what OS is or isn't installed?

It probably doesn't know but the bootloader doesn't load . This would be a reason to debug it. ))

[Krash]

I am looking at replacing my bios in VMware.

Why?

I feel that the ultimate knowledge of making a bios and boot loader is where you can replace the one that you are currently running. I obviously , don't want to try this in a hard machine.

[Krash]

I am reading this to mean that the BIOS image file that comes with your copy of VMware (to be used by, and run on, the virtualized CPUs - though I think you can also configure it to use the system's native BIOS instead) runs correctly when VMware itself is running under XP, but not when VMware is running under, say, Windows 10. Is this what you meant?

I am thinking that it's failing to load the boot loader or something. I really am not 100% sure. This is why I am wanting to debug it.

If so, then my question is: are you comparing behavior on a 32-bit version of XP to that running on some 64-bit version of Windows? Also, is the version of VMware the same on both, or two different versions, and if they are the same, is it a 32-bit version or a 64-bit version?

Version of VMware is the same.

Some information on how the two installations of VMware are configured, both in general and for the boot loader you are testing, might clarify things as well.

There is only one version of VMware being used workstation pro 12.

What I am thinking is that the problem is in the emulation of real mode operations on a system running in long mode. But I really would need to more details to say if that's the case or not.

Conversely, for the machine it is failing on (if it is two different ones), have you checked to make sure virtualization is in fact enabled in the motherboard's boot-time system configuration? It sounds like a no-brainer, but you'd be surprised how easy it is to forget the basic things like that, or change it unintentionally when you are trying to set up something else.

Also, have you tried testing the boot loader using a different virtualizer (such as running it in Hyper-V using the guest OS client, or probably more practically, something like VirtualBox, or QEMU for Windows), or an emulator such as Bochs?

I haven't . I am wanting to test it . I was thinking that debugging this would give me a clear idea of what is going on.

[Octocontrabass]

I feel that the ultimate knowledge of making a bios and boot loader is where you can replace the one that you are currently running. I obviously , don't want to try this in a hard machine.

I'm not sure if I agree with that statement.

In any case, bootloaders usually aren't very demanding of the BIOS. It'll probably be easiest to reverse-engineer the failing bootloader, write up some test cases that interact with your BIOS the same way the bootloader does, and compare results between your BIOS and a working BIOS.

[Schol-R-LEA]

I am sorry, but you didn't answer the question about the versions of Windows in question, and more specifically, whether the two versions are both 32-bit, both 64-bit, or if one is 32-bit and the other 64-bit. That was the more important question, frankly, though I guess I wasn't clear on this point; if so, I apologize, and will try to be more specific in my questions.

Also, I may not have been clear about my question regarding the VMware configuration. While knowing which version you are using is important, what is potentially more important is the settings, configuration files, etc.

[Schol-R-LEA]

I feel that the ultimate knowledge of making a bios and boot loader is where you can replace the one that you are currently running. I obviously , don't want to try this in a hard machine.

I'm not sure if I agree with that statement.

I am absolutely sure I don't.

Why not? First, both the BIOS and the bootloader are pretty much irrelevant to the operating system itself. These are details you want to suppress, not expose - they don't help, and are quite likely to confuse you or encourage you to tie things too closely to the hardware in question.

Regarding the BIOS, for the majority of systems, the really crucial aspects of the BIOS are the parts that abstract the motherboard's specific hardware and chipset - something that would be completely useless unless you had the details of both the hardware and the chipset.

Details, I might add, which for most systems are at least partly proprietary. And which most definitely wouldn't be present in the 'generic' BIOS in question.

Why? Because the hypervisor traps all the BIOS calls and reroutes them to the underlying ones, or more likely, just emulates them in the host OS's userland. I am not sure if the generic BIOS would actually work on an non-virtualized hardware, meaning that it is at best going to be misleading.

Also, while older BIOSes were usually written in assembly, it is my understanding that modern ones (including the generic one, most likely) are usually done partly in C - all the functions need to be written specifically for the hardware it is targeting rather than use standard libraries, and the compiler is probably either a non-standard one and/or one configured to avoid emitting certain code that wouldn't be appropriate (think of the --ffreestanding option for GCC, but with wider consequences), but still in C. Disassembling compiled code, especially compiled code that is probably very highly optimized, is likely to be an exercise in frustration.

(I feel like there was something else I wanted to mention, but hopefully I'll get back to it later.)

This does brings up another question related to my earlier ones: what are the hardware platforms you are working with? This is less likely to be a factor here, but it is worth knowing.

[Krash]

I feel that the ultimate knowledge of making a bios and boot loader is where you can replace the one that you are currently running. I obviously , don't want to try this in a hard machine.

I'm not sure if I agree with that statement.

In any case, bootloaders usually aren't very demanding of the BIOS. It'll probably be easiest to reverse-engineer the failing bootloader, write up some test cases that interact with your BIOS the same way the bootloader does, and compare results between your BIOS and a working BIOS.

I am wanting to debug one so I dont have to make several code comparisons. Anyway, the reasons are irrelevant . I was hoping for a sane solution to what should be a simple solution. Looking at one currently. If it works, then I will document it.

[Krash]

I am sorry, but you didn't answer the question about the versions of Windows in question, and more specifically, whether the two versions are both 32-bit, both 64-bit, or if one is 32-bit and the other 64-bit. That was the more important question, frankly, though I guess I wasn't clear on this point; if so, I apologize, and will try to be more specific in my questions.

Also, I may not have been clear about my question regarding the VMware configuration. While knowing which version you are using is important, what is potentially more important is the settings, configuration files, etc.

I want to end on debugging a bios on a x64 windiws 10 os.

[Krash]

I feel that the ultimate knowledge of making a bios and boot loader is where you can replace the one that you are currently running. I obviously , don't want to try this in a hard machine.

I'm not sure if I agree with that statement.

I am absolutely sure I don't.

Why not? First, both the BIOS and the bootloader are pretty much irrelevant to the operating system itself. These are details you want to suppress, not expose - they don't help, and are quite likely to confuse you or encourage you to tie things too closely to the hardware in question.

Regarding the BIOS, for the majority of systems, the really crucial aspects of the BIOS are the parts that abstract the motherboard's specific hardware and chipset - something that would be completely useless unless you had the details of both the hardware and the chipset.

Details, I might add, which for most systems are at least partly proprietary. And which most definitely wouldn't be present in the 'generic' BIOS in question.

Why? Because the hypervisor traps all the BIOS calls and reroutes them to the underlying ones, or more likely, just emulates them in the host OS's userland. I am not sure if the generic BIOS would actually work on an non-virtualized hardware, meaning that it is at best going to be misleading.

Also, while older BIOSes were usually written in assembly, it is my understanding that modern ones (including the generic one, most likely) are usually done partly in C - all the functions need to be written specifically for the hardware it is targeting rather than use standard libraries, and the compiler is probably either a non-standard one and/or one configured to avoid emitting certain code that wouldn't be appropriate (think of the --ffreestanding option for GCC, but with wider consequences), but still in C. Disassembling compiled code, especially compiled code that is probably very highly optimized, is likely to be an exercise in frustration.

(I feel like there was something else I wanted to mention, but hopefully I'll get back to it later.)

This does brings up another question related to my earlier ones: what are the hardware platforms you are working with? This is less likely to be a factor here, but it is worth knowing.

I think this is the best answer so far. I am looking into an answer for this.

[iansjack]

I believe that SimNow from AMD would allow you to debug the BIOS.

[Schol-R-LEA]

I think this is the best answer so far. I am looking into an answer for this.

I'm not sure I am following you, but OK.

BTW, you might want to look into the Open Firmware Initiative and OpenBIOS, which might be the sort of thing you are really looking for. I'm not sure, still, but it may be worth looking into.

Three things to note, however: First, the project pre-dates UEFI (though not the earlier EFI), and the wiki doesn't seem to have changed much after 2013, so using it with a UEFI motherboard may be a problem. I may be wrong, however; the OpenHub page say that it is moderately active, and the GitHub repo has updates within the past two months.

Second, it looks to me that it is more of an abstraction layer over the existing firmware, rather than a truly generic BIOS (which, as I mentioned, wouldn't really be feasible - I am pretty sure the 'generic BIOS' in VMware is the same, hell, for all I know it is an implementation of OpenBIOS).

Third, while it is designed to interop with C code, the wiki states that much of OpenBIOS itself is written in Forth, so understanding the OpenBIOS code would mean learning Forth if you don't already know it (it isn't too hard, being an extremely simple language by design, but it is drastically different from most Algol-Pascal-C family languages so it would take some getting used to).

Make of this what you will.