problems with stack and pointers

[Octocontrabass]

I played a bit with the stack segment in the GDT and my conclusion is that when hardware virtualization is enabled then the vm doesn't really like if the base of the stack segment is 0. Is there any restriction to the stack base?

No, but VirtualBox may not be prepared to handle separate data and stack segments. Operating systems typically load the same segment selector into DS and SS.

[SpyderTL]

VirtualBox is actually open source, so you can see for yourself if this is a bug. You can even submit a bug, or even submit a bug fix if you want. I've done it myself. The vbox guys are pretty helpful.

The reality is that VirtualBox and VMware will both cut corners if it makes Windows run 1% faster. CPU accuracy is slightly lower priority than performance.

In fact, this may already be a known issue, but just not high enough priority to fix if it doesn't affect Windows.

Check out VirtualBox.org. They have a forum and a bug list if you want to truly get to the bottom of this issue.

What's does your stack GDT entry look like when it crashes?

[Andrej]

Hi,
When I have the following GDT then it seems to be working - I did not thested everithing, just I did not get tripple-fault after one call instruction:

Code: Select all

StartOfGDT:
    zerodescriptor:
        .quad   0
    OScode:
        .quad   0x00cf9a000000ffff
    OSdata:
        .quad   0x00cf92000000ffff
    OSstack:
        .quad   0x00C0960000000001
    GDTend:

But if I set the limit for the stack (if I remember correctly) higher then 0x4 than the vm goes to guru meditation state.

If the stack entry looks like:

Code: Select all

StartOfGDT:
    ...
    OSstack:
        .quad   0x00C0960000010005 /*the limit probably can be anything, I did not managed to put the vm to guru meditation*/
    GDTend:

then it works fine. From these usecases I concluded that the base of the stack cannot be 0.
Thank you for the information. I'll contact to virtualbox.

Best Regards,
Andrej

[linuxyne]

Tried the below with a floppy image.
Did not crash with qemu, bochs or virtualbox.
Nor did it crash with the 0x18'th GDTE set to 0x00c09600ac000005.

Code: Select all

.code16
/* add a jmp to set the cs to a known value. */
_start:
        ljmp $0x0, $begin
begin:
        cli;
        cld;

        xorw %ax, %ax;
        movw %ax, %ds;
        movw %ax, %es;

        lgdt bt_gdtr;

        movl %cr0, %eax;
        orw $1, %ax;
        movl %eax, %cr0;

        ljmp $0x8, $pmode;

.balign 8
bt_gdt:
        .quad 0
        .quad 0x00cf9a000000ffff
        .quad 0x00cf92000000ffff
        .quad 0x00c0960000000005
bt_gdtr:
        .word bt_gdtr - bt_gdt - 1
        .int bt_gdt

.code32
pmode:
        movw $0x10, %ax;
        movw %ax, %ds;
        movw %ax, %es;
        movw $0x18, %ax;
        movw %ax, %ss;
        xorl %esp, %esp;

        pushl $0xabcdabcd;
        popl %eax;

        /* EAX here is NOT 0xabcdabcd, but is the contents of the 
         * linear address 0xfffffffc.
         *
         * The pushl insn, must have attempted a write to linear 0xfffffffc,
         * but that address probably maps the BIOS read-only memory.
         */
1:
        jmp 1b;

        . = _start + 510
        .byte 0x55
        .byte 0xaa

Code: Select all

as a.s
ld -Ttext 0x7c00 --oformat=binary a.out -o a.bin
dd conv=notrunc if=a.bin of=floppy.img

[Andrej]

Hi,
I'm using ISO image to boot.

Br,
Andrej

[linuxyne]

I'm using ISO image to boot.

I think that using ISO or floppy should not affect the GDT or the behaviour of the machine when using the given GDT.

[SpyderTL]

If you comment out these lines, does the problem go away?

Code: Select all

    mov     $STACK_BASE,%ebx
    movl    $STACK_LIMIT,%ecx
    movl    $4096, %eax
    mull    %ecx
    addl    %ebx,%eax
    sub     $16,%eax
    mov     %eax,%esp

You can try replacing it with something simple like

Code: Select all

 mov 0x1000, %eax
 mov %eax, %esp

[Andrej]

Hi,
Replacing those lines doesn't help, but if I disable harware virtualization it does.
Which version of VirtualBox are you using?

Br,
Andrej

[Andrej]

Hello,
Another strange thing happened when hardware virtualization was enabled:
I was trying to change the GDT (since the boot loader implements only plain flat model and I wanted to replace it to protected flat model) with the following code:

Code: Select all

cli
jmp     _start

memory_descriptor:
    .rep 12
    .byte 0
    .endr

oldGDTdescriptor:
    .word   0
    .int    0

GDTdescriptor:
    .word   0
    .int    0

.globl _start
_start:
    call    get_gdt_base
    lea     GDTdescriptor, %ebx
    movl    %eax, %ds:2(%ebx)
    lea     memory_descriptor, %eax
    sgdt    (oldGDTdescriptor)
    push    %eax
    call    create_base_gdt
    movw    $8, %dx
    mulw    %dx
    decw    %ax
    movw    %ax, %ds:(%ebx)
    lgdt    (GDTdescriptor)
    movl    $0x10,%eax
    mov     %ax,%ds
    mov     %ax,%es
    mov     %ax,%fs
    mov     %ax,%gs
    mov     %ax,%ss
    jmp     $8,$next
    next:
    movl    $0x3FFE0, %eax
    movl    %eax, %esp
    call    main

Function "get_gdt_base" gives back a memory location where the GDT should be placed. No code and no useful data are on that memory location.
Function "create_base_gdt" loads the following GDT to the memory area returned by "get_gdt_base":

Code: Select all

0x0
/*code segment*/
0x00C09A0000008000
/*data segment*/
0x00C0920000008000

When the hardware virtualization is enabled IRQ 6 (invalid opcode exception) is fired constantly. But when hardware virtualization is disabled then everything is fine.
Do I miss something or it is another possible bug in VirtualBox.
I'm using VirtualBox 4.3.36_Ubuntu r105129

Best Regards,
Andrej

[linuxyne]

To show that a problem is caused by a bug in vbox, one needs to expose the suspected bug by building a minimal program which strictly adheres to the published hw & sw specifications, but which still fails to run as expected on vbox.