I just thought that this code may be interesting to other people who did not attend this conference.

The demo code includes mainly x86 specific stuff and it is truly demo code, so don’t just copy it into another project. Even if it works at first sight, it it is highly likely to break sooner or later

The code contains samples for:

• A small “Hello World” bootsector in realmode
• A sample how to enable the A20 gate. This works at least in QEMU
• Loading a barebone-kernel written in C by GRUB
• Switching to protected mode and writing to the textmode framebuffer
• Handling interrupts in protected mode using the old PIC
• Configuring and using the old PIT (Timer)
• Switching to longmode (64 Bit)
• A multitasking demo how to do context switching

The first two samples are completely written in Assembly and are loaded directly by the BIOS from a floppy drive. All other samples are mainly written in C spiced with some Assembly and are loaded from a FAT formatted floppy disk by a GRUB bootloader.

For those of you who speak german, here are the slides of the conference:
Talk
Workshop

If you do anything with this demo code, I would appreciate to hear about your project or experiences. Also, If there are specific questions or problems about/with this code which are not easily resolvable by Googling and using your brain, feel free to ask in the comments.

Feel free to Flattr this post at flattr.com, if you like it.

Doing this with real hardware is kinda risky and complex.
But what about virtual machines like VMware? They have a BIOS, but how can we get our hands on it?
As I’m using Mac OS X for all my daily work, I’m using VMware Fusion as a virtualization program.

The BIOS seems to be hidden inside the virtual machine monitor executable itself.
To make our lifes easier, we are going to extract only the x86_64 part out of the universal binary with the following command:

lipo /Libary/Application\ Support/VMware\ Fusion/vmware-vmx -thin x86_64 -output /Users/user/Desktop/vm64

Now, we have a Mach-O file with only one architecture, which is x86_64.
It doesn’t matter if you are dumping the BIOS out of the i386 or x86_64 version of the binary. It should be the same for both architectures.

After that, we can extract the appropriate section in the Mach-O file which contains the BIOS itself:

segedit /Users/user/Desktop/vm64 -extract __VMWARE bios440 /Users/user/Desktop/bios440.rom

And here, you go: bios440.rom contains your VMware BIOS.

After you modified it to your wishes, you can use a handy VMware feature which lets you specify a custom BIOS for a virtual machine inside its vmx-file.
Just add this line to the vmx-file of the machine you want a custom BIOS for and place the rom file in the proper folder:

bios440.filename = "bios.rom"

Happy BIOS modding!

Feel free to Flattr this post at flattr.com, if you like it.

Nachdem ich dann auch irgendwann mal raushatte, wie ich das vierstufige (!) Paging mit 4KB großen Pages beim Booten zusammenbauen konnte, um so einen Prozessor in den Long Mode zu bekommen, hab ich mich mal an die Virtualisierung machen wollen.
Zu diesem Zeitpunkt saß ich allerdings schon im Hackcenter.

Wie ich dann, mal wieder, feststellen musste, hat so ein Low Level Zeug einen unglaublichen Rattenschwanz, den man immer wieder hinter sich herzieht. In diesem konrekten Fall brauchte ich also ein vernünftiges Interrupthandling. Ist ja schnell implementiert, dachte ich mir und kopier mir meinen Code aus meinen anderen Projekten fröhlich zusammen.

Interrupts konnte ich dann handlen. Problem war jetzt nur, dass 2 Instruktionen nach dem Aktivieren der Interrupts sofort der Interrupt #8 auftrat, was nach Dokumentation ein Double Fault gewesen sein müsste. Dieser tritt aber nur nach einer fatalen, vorhergegangenen Exception auf, wovon ich aber nichts mitbekommen habe. Wieso fliegt da also ein Double Fault? Nichtmal die 2 Instruktionen, die nach dem setzen des Interrupt Enable Flags ausgeführt wurden konnten einen solchen Interrupt auslösen, weil es Sprünge zu sich selbst waren, um die CPU in einer Endlosschleife zu halten.

Kommen wir zurück zum Rattenschwanz: Nachdem ich dann die Interrupt Handler und die Verwaltung der IDT hatte, habe ich noch Routinen zur Verwaltung der GDT implementiert. Es funktionierte immernoch nicht, was allerdings zu erwarten war, da es mehr eine Verzweifelungstat war als ein richtiger Lösungsansatz. Wir sind zu diesem Zeitpunkt bei Tag 3 des Kongresses.
Allerdings war das ja auch nicht das Einzige, was ich da gemacht habe. Gab ja noch Vorträge.

Danach gings ans Debuggen. Ich habe VMware probiert, um zu sehen, was das Ding sagt. Wie erwartet: nichts. Es fehlen einfach die Debuggingmöglichkeiten unter Mac OS mit VMware.
Dann gibts noch Qemu, an den man einen GDB klemmen kann. Gesagt getan. Nach wie vor nichts gefunden.
Als letztes bin ich mit dem integrierten Debugger in Bochs dem Kram zu Leibe gerückt, mit dem man seinen Code auf Assemblerebene Debuggen konnte. Auch hier habe ich wieder nichts gefunden.

Was war das Ende vom Lied? Es gibt einen extra Chip auf x86 Systemem, der externe Interrupts handlet. Früher war das der PIC (Programmable Interrupt Controller) und heute ist es der APIC (Advanced Programmable Interrupt Controller), der auch Mehrprozessorsysteme ohne Gefrickel unterstützt.
Diese Chips kann man so konfigurieren, dass jeder externe Interrupt (Tastatur, Floppy, Timer etc) auf einen der 256 Interrupts der CPU gemappt werden kann.

Irgendein Stück Software vor meinem Kernel hat genau das anscheinend mit dem Timerinterrupt gemacht und ihn auf Interrupt #8 gelegt.
Das würde dann auch erklären, warum bei einem Double Fault eigentlich ein Errorcode auf den Stack gepusht werden sollte, was bei mir aber nie passiert ist. Es war schlicht und ergreifend kein Double Fault.

Also hab ich dann doch, entgegen meiner vorherigen “Brauchste eh nich”-Meinung, auch noch Code hinzugefügt, der den PIC (eigentlich sind es 2 PICs) entsprechend konfiguriert und die 16 Interrupts, die er verwalten kann, hinter die Exceptions mappt.

Was ist? Es funktioniert endlich.

Und so kann man sich wunderschön auf die Fresse legen und Zeit verbraten.
Ich will nicht sagen ich hab nichts gelernt, genervt hat es aber doch schon ziemlich. Gedauert hat der ganze Prozess jetzt 6 Tage. Und ich hab immernoch keinen virtualisierten Code laufen.

Feel free to Flattr this post at flattr.com, if you like it.