Real undefined behavior - bochs

[Cyao]

Hello everyone! I've been trying to get a 64 bit idt made, but somehow in the process I broke litteraly everything

Now the only thing my os does (in bochs) is switch to 32 bit mode and crash, I managed to track it down to here using the bochs's debugger

Code: Select all

Next at t=35427029
(0) [0x000000007cfa] 0008:0000000000007cfa (unk. ctxt): wrmsr                     ; 0f30
<bochs:26> 
Next at t=35427030
(0) [0x000000007cfc] 0008:0000000000007cfc (unk. ctxt): mov eax, cr0              ; 0f20c0
<bochs:27> 
Next at t=35427031
(0) [0x000000007cff] 0008:0000000000007cff (unk. ctxt): or eax, 0x0b8000bf        ; 0dbf00800b
<bochs:28> 
Next at t=35427032
(0) [0x000000007d04] 0008:0000000000007d04 (unk. ctxt): add byte ptr ds:[eax-72], cl ; 0048b8
<bochs:29> 
Next at t=35427033
(0) [0x000000007d07] 0008:0000000000007d07 (unk. ctxt): and byte ptr ds:[edi], cl ; 200f
<bochs:30> 

You can see that the instruction is now add byte ptr ds:[eax-72], cl ; 0048b8 (after this its just gets garbage instructions from nowhere and manage to cause a tripple fault) after the bitwise or , but my code is like this

Code: Select all

    mov eax, cr0                 ; Set the A-register to control register 0.
    or eax, 1 << 31              ; Set the PG-bit, which is the 32nd bit (bit 31).
    mov cr0, eax                 ; Set control register 0 to the A-register.

    jmp $

and I've also tried to run it on qemu and everything is fine. Does anyone know what is wrong with bochs? my bochsrc.txt is like this https://github.com/cheyao/AsmOS/blob/b1 ... /bochs.txt

[Cyao]

Ahh Oh god it was me mispelling a number again, thought the bootsect's size was 0x100

And now I am back to fixing my idt, I have this error:

Code: Select all

LIDT64_Ms: loaded base64 address is not in canonical form!
00035427891e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427891e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427891i[CPU0  ] CPU is in long mode (active)

Anyone knows what does base64 address is not in canonical form mean?

thanks!

[kzinti]

Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64

(...), the AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to sign extension). If this requirement is not met, the processor will raise an exception.[11]: 131  Addresses complying with this rule are referred to as "canonical form."[11]: 130  Canonical form addresses run from 0 through 00007FFF'FFFFFFFF, and from FFFF8000'00000000 through FFFFFFFF'FFFFFFFF, for a total of 256 TB of usable virtual address space.

[Cyao]

Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64

Hmm then how can I produce the coninical adress in c?

[kzinti]

You don't make a canonical address in C, you just use canonical addresses for virtual addresses when building your page tables.

You haven't show us the part where you use the LIDT instruction, so there is little to go with here.

But from what you posted it looks like:

1) Your IDT is not at a canonical address. Where did you put it (virtual address)?
2) Your IDT has invalid descriptor(s) (the 4 dword of each descriptor is reserved and should be zero, as per the error message).

[Cyao]

https://github.com/cheyao/AsmOS/blob/b1 ... /idt.c#L27

It's just here, the code is loaded into 0x7E00, should have nothing special with it, really wierd

[kzinti]

Line 26: Your IDT should have 256 entries, not 255.
Line 47: I see "u64int" instead of "uint64_t", how does that even compile?
Line 48: Your limit is wrong, it should be the size of the IDT minus 1, so 256 * 16 - 1, or sizeof(idt_entry_t) - 1

The rest looks good, but there might be other issues.

If your code and data is around 0x7E00, Bochs shouldn't complain about an invalid address. Are you able to print the address of your IDT (i.e. &idt_entry_t[0]) so we can see what it is?

[Cyao]

Line 26: Your IDT should have 256 entries, not 255.

The array dosen't start at 0? So idt[255] = 256 entries

Line 47: I see "u64int" instead of "uint64_t", how does that even compile?

This is just me being a bit lazy, I prefer u64int, but all wiki code is uint64_t, so I declared them both

Line 48: Your limit is wrong, it should be the size of the IDT minus 1, so 256 * 16 - 1, or sizeof(idt_entry_t) - 1 - which incidently is not a type, so lose the _t suffix?

I think this should not be the problem, less entries = less error possibility, so im just trying to make 2 gates

If your code and data is around 0x7E00, Bochs shouldn't complain about an invalid address. Are you able to print the address of your IDT (i.e. &idt_entry_t[0]) so we can see what it is?

Ye just wait a min ima implement a itoa

[kzinti]

The array dosen't start at 0? So idt[255] = 256 entries

idt[255] is 255 entries, with indices from 0 to 254.

[kzinti]

Since you are using Bochs, you can just set a breakpoint and see what value is loaded into the IDT. See "Magic Breakpoint" here: https://wiki.osdev.org/Bochs

[Cyao]

The idt_entry_t is in 0x7ffd7 (using bochs) looks a bit high to me, very wierd

And now bochs still shows the error
00035427891e[CPU0 ] LIDT64_Ms: loaded base64 address is not in canonical form!
00035427043e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427043e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0

[kzinti]

You flush_idt function is wrong: https://github.com/cheyao/AsmOS/blob/b1 ... tr.asm#L59

1) You are using %eax, which is a 32 bits register.
2) In 64 bits mode, the first parameter is in register %rdi (and not on the stack). This is assuming you are using the System V calling convention. If you use the Microsoft one, the parameter will be in %rax.

[Cyao]

You flush_idt function is wrong: https://github.com/cheyao/AsmOS/blob/b1 ... tr.asm#L59

1) You are using %eax, which is a 32 bits register.
2) In 64 bits mode, the first parameter is in register %rdi (and not on the stack). This is assuming you are using the System V calling convention. If you use the Microsoft one, the parameter will be in %rax.

Ahh thanks a lot! It fixed my problem!