OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 3:19 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: Real undefined behavior - bochs
PostPosted: Fri Nov 11, 2022 2:52 pm 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
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:
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:
    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

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Fri Nov 11, 2022 2:55 pm 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
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:
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!

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Fri Nov 11, 2022 5:59 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64

Quote:
(...), 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.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 1:06 am 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
kzinti wrote:
Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64

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

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 1:32 am 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
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).

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 1:40 am 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
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

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 1:47 am 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
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?

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 1:58 am 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
kzinti wrote:
Line 26: Your IDT should have 256 entries, not 255.

The array dosen't start at 0? So idt[255] = 256 entries
kzinti wrote:
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
kzinti wrote:
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
kzinti wrote:
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

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 2:03 am 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
cyao1234 wrote:
The array dosen't start at 0? So idt[255] = 256 entries

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

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 2:16 am 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
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

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 2:22 am 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
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

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 5:27 am 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
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.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Real undefined behavior - bochs
PostPosted: Sat Nov 12, 2022 5:56 am 
Offline
Member
Member

Joined: Tue Jun 07, 2022 11:23 am
Posts: 78
Location: France
kzinti wrote:
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!

_________________
https://github.com/cheyao/Achieve-Core


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: 8infy, Bing [Bot] and 59 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group