Octocontrabass wrote:
Code:
gdtr:base=0x0000000000008010, limit=0x1d
That's a really weird limit. What's going on there?
I've fixed the limit to be 0x1f (i.e. 0x20). That was indeed a bug. Thanks!
Code:
<bochs:1> b 0xc01e
<bochs:2> c
(0) Breakpoint 1, 0x000000000000c01e in ?? ()
Next at t=908928882
(0) [0x00000000c01e] 0008:000000000000c01e (code+1e): mov ss, ax ; 8ed0
<bochs:3> disasm 0xc000 0xc02d
000000000000c000: ( code+0): push r15 ; 4157
000000000000c002: ( code+2): push r14 ; 4156
000000000000c004: ( code+4): push r13 ; 4155
000000000000c006: ( code+6): push r12 ; 4154
000000000000c008: ( code+8): push rbp ; 55
000000000000c009: ( code+9): push rbx ; 53
000000000000c00a: ( code+a): sub rsp, 0x00000000000000d8 ; 4881ecd8000000
000000000000c011: ( code+11): xor rax, rax ; 4831c0
000000000000c014: ( code+14): push rax ; 50
000000000000c015: ( code+15): popf ; 9d
000000000000c016: ( code+16): mov ax, 0x0010 ; 66b81000
000000000000c01a: ( code+1a): mov ds, ax ; 8ed8
000000000000c01c: ( code+1c): mov es, ax ; 8ec0
000000000000c01e: ( code+1e): mov ss, ax ; 8ed0
000000000000c020: ( code+20): mov rsp, 0x0000000000007dea ; 48c7c4ea7d0000
000000000000c027: ( code+27): mov fs, ax ; 8ee0
000000000000c029: ( code+29): mov gs, ax ; 8ee8
000000000000c02b: ( code+2b): xor eax, eax ; 31c0
<bochs:4> creg
CR0=0xe0040033: PG CD NW AC wp NE ET ts em MP PE
CR2=page fault laddr=0x0000000000000000
CR3=0x000000008000
PCD=page-level cache disable=0
PWT=page-level write-through=0
CR4=0x000007a6: cet pke smap smep osxsave pcid fsgsbase smx vmx OSXMMEXCPT umip OSFXSR PCE PGE mce PAE pse de TSD PVI vme
CR8: 0x0
EFER=0x00000501: ffxsr nxe LMA LME SCE
XCR0=0x00000001: pkru hi_zmm zmm_hi256 opmask bndcfg bndregs ymm sse FPU
<bochs:5> sreg
es:0x0010, dh=0x00009300, dl=0x00000000, valid=1
Data segment, base=0x00000000, limit=0x00000000, Read/Write, Accessed
cs:0x0008, dh=0x00209900, dl=0x00000000, valid=1
Code segment, base=0x00000000, limit=0x00000000, Execute-Only, Non-Conforming, Accessed, 64-bit
ss:0x0002, dh=0x00009300, dl=0x0020ffff, valid=7
Data segment, base=0x00000020, limit=0x0000ffff, Read/Write, Accessed
ds:0x0010, dh=0x00009300, dl=0x00000000, valid=1
Data segment, base=0x00000000, limit=0x00000000, Read/Write, Accessed
fs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
gs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
ldtr:0x0000, dh=0x00008200, dl=0x0000ffff, valid=1
tr:0x0000, dh=0x00008b00, dl=0x0000ffff, valid=1
gdtr:base=0x0000000000008010, limit=0x1f
idtr:base=0x0000000000000000, limit=0x0
Then tried it in VirtualBox, and it still aborts. Here are the last 5 lines of VBox.log again showing it ends at boot:
Code:
00:00:01.122588 VMMDev: Guest Log: BIOS: ata0-0: PCHS=20/16/63 LCHS=20/16/63
00:00:01.125089 PIT: mode=2 count=0x48d3 (18643) - 64.00 Hz (ch=0)
00:00:01.135825 PIT: mode=2 count=0x10000 (65536) - 18.20 Hz (ch=0)
00:00:01.136004 VMMDev: Guest Log: BIOS: Boot : bseqnr=1, bootseq=0002
00:00:01.136282 VMMDev: Guest Log: BIOS: Booting from Hard Disk...
Octocontrabass wrote:
Out of curiosity, does VirtualBox still crash if you load the segment registers with null selectors? SS requires a valid segment in ring 3 and when performing some stack switching operations, but all data segments may be null outside those cases.
I'm uncomfortable going that route at the moment, maybe I'm not desperate enough yet. I'm curious if this technique - loading SS with a null segment - has been tested on a wide range of hardware.
I like the idea of using inline assembler at file scope. I want to try that next.