OSDev.org

Hi,

I have a boot code that initializes protected mode without paging and jumps into the protected mode code.
After the switch however I observe weird memory behavior.

When I write to the memory addresses that I get from registers they end up happening near 0x0 address instead of 0x100000.

I have tried hardcoding mov dword [0x100000], reg32 and it does not work.
I've decoded an instruction:

0x83f8: mov %edi,0x100000

EDI at that time was: 0x101001

The instruction bytes are: (gdb) x/6b 0x83f8
0x83f8: 0x89 0x3d 0x00 0x00 0x10 0x00

Unfortunately after it gets executed I get:

(gdb) x/1xw 0
0x0: 0x00101001
(gdb) x/1xw 0x100000
0x100000: 0x00000000

Similar story for mov 0x1337, [0x100000]

(gdb) x/10i $eip-11
0x830a: movl $0x1337,0x100000
0x8314: hlt


(gdb) x/1w 0x100000
0x100000: 0x00000000
(gdb) x/1w 0x00000
0x0: 0x00001337


In VirtualBox it all works fine.


I have populated GDT correctly with standard dummy 4G descriptors with base=0 and limit field with all bits set, for null selector, code, data and stack selectors.
CS is set to code selector, DS, ES, FS, GS are set to data selectors, and SS is set to stack selector.

I have no idea why is VMware Fusion behaving like this.


Here's register dump from gdb:


(gdb) i r
eax 0x100000 1048576
ecx 0xc 12
edx 0x0 0
ebx 0x60 96
esp 0x900 0x900
ebp 0x900 0x900
esi 0xa60 2656
edi 0x9e950000 -1634402304
eip 0x8315 0x8315
eflags 0x200006 2097158
cs 0x8 8
ss 0x18 24
ds 0x10 16
es 0x10 16
fs 0x10 16
gs 0x10 16

I have absolutely no idea what is going on and why is VMware Fusion behaving like this. Any suggestions appreciated.

Here's the the relevant part of the 32-bit code that puts writes to wrong memory locations:
EDIT:

Here are values of GDT in VMware


0xb20: 0x0000000000000000 0x00cf9b000000ffff
0xb30: 0x00cf93000000ffff 0x00cf93000000ffff

Other than the bunch of syntax errors in your ASM (you're mixing intel and ATT syntax, and the order is wrong on occasion), are you debugging the OS or did you start gdb on the virtual machine itself - some use segmentation internally to separate the virtualizer from the executing code, which means that some address in your code does not correspond to the address seen by your code.
The other possible explanation is that your VM only has 1mb of ram....

Try writing a bunch of data to video ram (0x000b8000) in a loop and see if it shows up on the screen - if it does you know your segmentation code is not the problem:

Combuster wrote:Other than the bunch of syntax errors in your ASM (you're mixing intel and ATT syntax, and the order is wrong on occasion), are you debugging the OS or did you start gdb on the virtual machine itself - some use segmentation internally to separate the virtualizer from the executing code, which means that some address in your code does not correspond to the address seen by your code.

I'm writing everything using intel syntax with NASM but to debug VMWare I attach with the GDB to it, so it displays everything in ATT syntax.

Combuster wrote: The other possible explanation is that your VM only has 1mb of ram....

Try writing a bunch of data to video ram (0x000b8000) in a loop and see if it shows up on the screen - if it does you know your segmentation code is not the problem:

Code: Select all

.loop:
mov ax, 0x0741
mov edi, 0xb8000
mov ecx, 4096
rep stosw
jmp .loop ;avoid cli;hlt; because that is known to screw up on some emulators 

I've double checked, and the VM has 256 megabytes of memory configured. The code above fills entire screen with a letter 'A'.


As a side note: here's memory map via e820 method:

The first quad is base, the second quad is limit, the third
are ACPI extension and region type fields

Just a guess: Does VMWare Fusion use binary translation? Doesn't binary translation mess with the addresses of stuff?

I expect that the code actually performs the actions properly in respect to itself - the vram test worked exactly as expected. The reply was however not conclusive enough to determine if the OP is debugging the emulator (as running something like gdb emulator -conf myos.cfg does not have the intended effect as noted before) or uses some gdb stub built into vmware (in which case a connect command needs to be given)

In any case, debugging the VM host instead of the guest is just asking for trouble. It might somewhat work if the code is actually mapped to their original addresses, but in the case of a VM using the GDT trick or any other translation step, you won't be able to accurately find your data.

Have you heard of the A20?

DavidCooper wrote:Have you heard of the A20?

Ahhh..... yes, I have heard of it I totally forgot to enable it.
It fixes everything.

Thanks