Should IDT be seen from user mode

[Galgr]

Hello.
Working with interruption handling on my OS.
I set up IDT and it seems to be working (call 'int 0' for example goes where it should to go), but if I do same thing from user mode CPU resets.
I investigated that if I won't restrict kernel memory pages to be read from user mode then everything is ok. But I'm quite sure that kernel address space should be inaccessible for user processes (except maybe some shared structures, but it's not that case, is it?).
So, what I'm doing wrong? Maybe I missing something?
Thanks for help and sorry for my english.

Some additional info (if required):
IDT[0] has type 0xE, dpl 0, selector 0x08 (kernel code selector)
I set up TSS too: esp0=kernel stack base, ss0=kernel data selector, type 0x9
Calling from user space like 'int 0' and I successfully enter user space (CPU resets after 'int 0')
Also called through 'div' (mov ax,1; mov cx,0; div cx) and with dpl 3 for IDT[0]

[bluemoon]

Read the manual again, the IDT has a field for user level.

Some additional info (if required):
IDT[0] has type 0xE, dpl 0, selector 0x08 (kernel code selector)

That's it, the DPL=0 you assigned.

Calling from user space like 'int 0' and I successfully enter user space (CPU resets after 'int 0')

What are you talking about? Did I missed something?
user-space entering user-space do not make any sense to me, "successfully" and "reset" are contradicts to each other.

[bluemoon]

Also called through 'div' (mov ax,1; mov cx,0; div cx) and with dpl 3 for IDT[0]

Exceptions (eg div by zero) are generated by the CPU itself and do not restricted by the DPL field, it is totally different with implicitly invoke INT n.

[Galgr]

Sorry, I really described it weird.
I mean that I can enter user space (switched page directory and run user process) from kernel and then CPU executes user instructions. When it reaches 'int 0' or division by zero (I tried both) it resets

[bluemoon]

Since your IDT entry has DPL=0, when user mode code execute INT n, General Protection Fault is trigger.
If you do not handle such #GP it will cause Double Fault.
If you do not handle such #DF the machine reset due to tripple fault.

For the case of divid by zero, the exception handler should be invoked even the DPL field in IDT is zero, perhaps there is other bugs causing #DF.

[Galgr]

Since your IDT entry has DPL=0, when user mode code execute INT n, General Protection Fault is trigger.
If you do not handle such #GP it will cause Double Fault.
If you do not handle such #DF the machine reset due to tripple fault.

Yes, I knew that. I have handler for general protection fault and double fault. I first tried division by zero and when it didn't work, I tried 'int 0' expecting general protection fault.

perhaps there is other bugs causing #DF.

Seems my case.

Thank you for your help. I appreciate that.

[Galgr]

It seems that problem is in user process page directory. I created it like that: copy entry from kernel page directory and reset rights.
Code example:

Code: Select all

...
proc->page_directory[i]= KERNEL_PAGE_DIRECTORY[i];
proc->page_directory[i]&= ~(PTE_W|PTE_U);
...

Now I don't remove write right:

Code: Select all

proc->page_directory[i]&= ~(PTE_U);

And everything works well!

Can somebody explain this for me? Is it a good decision? And why this works? (I thought kernel always can read/write its memory)

[Combuster]

I thought kernel always can read/write its memory

Not really. Have you checked the WP bit in the control registers?

[Galgr]

Not really. Have you checked the WP bit in the control registers?

Oh, now I see. Everything is clear now.
Thanks.