Kernel Mapping?

[Raven]

Hi

It is me again with couple of questions but this time it is more like confusions.
So let me be straight:

1. Is there any potential problem in having kernel in lower half?
Let me make my point clearer, I loaded my kernel at 0x100000 and have it identity mapped from 0 to end symbol done by kernel code itself. This means my kernel is in lower half, is there any problem with it in long run?

2. I have identity mapped my kernel, is this ok?

3. Why should we map kernel address space in every processes address space, whether ring 0 or ring 3?
Can't we have a kernel address space not sticked in every tasks address space?

4. If I have loaded my kernel at 0x100000 and takes upto 1mb space (say) then can i compile my programs to
a) 0 vma
b) 0x200000 vma
c) any address


5. Does sticking kernel space in user tasks in this case ( point 4 ) matter?

These questions rather confusions if answered will definitely make my understanding clear.
Please help as u guys have always.
I know these questions may sound silly, but this is what is right now in my mind.
Please help!

[pcmattman]

Hi,

1. Is there any potential problem in having kernel in lower half?

No - as long as your user applications don't conflict with the lower address it's fine.

2. I have identity mapped my kernel, is this ok?

There's no reason why it isn't.

3. Why should we map kernel address space in every processes address space, whether ring 0 or ring 3?

You do that so that the kernel can be called from userspace without an expensive switch to the kernel address space. There's still protection in the form of paging, and you define the avenues through which user programs communicate with the kernel.

Can't we have a kernel address space not sticked in every tasks address space?

You *can*, but it makes things far more complicated (IMO).

4. If I have loaded my kernel at 0x100000 and takes upto 1mb space (say) then can i compile my programs to
a) 0 vma
b) 0x200000 vma
c) any address

On my previous project I had the kernel at 0x100000 and applications linked at 0xC0000000. You can have your applications anywhere as long as they do not overwrite the kernel address space.

5. Does sticking kernel space in user tasks in this case ( point 4 ) matter?

It does only if the point at which the program is loaded conflicts with the kernel.

[egos]

1. Is there any potential problem in having kernel in lower half?

Yes, there is. When you will decide to resize the kernel space, you will need to move the fixed base of application (user) space, i.e. you will need recompile all your applications.

2. I have identity mapped my kernel, is this ok?

Yes, it's just your choice. But for me it's not so good because I'm allocating and mapping extended memory only dynamically.

3. Why should we map kernel address space in every processes address space, whether ring 0 or ring 3?

It's monolitic architecture...

Can't we have a kernel address space not sticked in every tasks address space?

Yes, we can, but it's not monolitic architecture.

4. If I have loaded my kernel at 0x100000 and takes upto 1mb space (say) then can i compile my programs to...

a) 0 vma - It's not so good. In the beginning of virtual address space usually presents NULL-pointer hole.
b) 0x200000 vma - It's not so good. 1 mb for kernel space is too small. 1-2 gb (for 32-bit platforms) is normal.
c) any address - Which?

5. Does sticking kernel space in user tasks in this case ( point 4 ) matter?

See above

[Raven]

Thanks everybody

1. Is there any potential problem in having kernel in lower half?

No - as long as your user applications don't conflict with the lower address it's fine.

This is what I fail to understand, what does it mean when we say user applications don't conflict with lower address?
I mean all the addresses are virtual for example kernel's vma 0 mapped to pma 0 and user's vma 0 mapped to pma 0x200000 (say).
How will there be a conflict?
Please correct me
Please explain.

3. Why should we map kernel address space in every processes address space, whether ring 0 or ring 3?

You do that so that the kernel can be called from userspace without an expensive switch to the kernel address space. There's still protection in the form of paging, and you define the avenues through which user programs communicate with the kernel.

Does it mean for example i want printf() routine of kernel to be called from my ring0 or ring3 process, then there is no need of changing address space as kernel space is already mapped and I can simply use software interrupt?
I mean let int 0x81 in my system displays current time at left-top of screen, all i need to do is call set_interrupt(0x81,proc_time) inside my kernel where proc_time() uses print routine to display time. And in case of my application i will simply do int 0x81.
Please correct me.
Please explain more.


3. Why should we map kernel address space in every processes address space, whether ring 0 or ring 3?

It's monolitic architecture...

Can't we have a kernel address space not sticked in every tasks address space?

Yes, we can, but it's not monolitic architecture.

So it is all design choice, but what are the advantages of monolithic ( i mean mapping kernel in every address space )?
Is this what i quoted above?

[pcmattman]

Hi,

This is what I fail to understand, what does it mean when we say user applications don't conflict with lower address?
I mean all the addresses are virtual for example kernel's vma 0 mapped to pma 0 and user's vma 0 mapped to pma 0x200000 (say).
How will there be a conflict?

If the kernel is in your application address spaces, you do not want to have your applications loaded in a location that could potentially overwrite your kernel. Say the application is linked to run at 0x100000, and your kernel is the same - when the application is loaded it'll want to overwrite the kernel. Not good!

I would suggest not having the application starting at 0x0 as, firstly, you can't have page faults on NULL pointer accesses, and secondly, if your kernel is at 0x100000 that limits you to 1 MB binaries that you can load. You also want to try to make things as extensible as possible, because it can be difficult to change things around later.

Does it mean for example i want printf() routine of kernel to be called from my ring0 or ring3 process, then there is no need of changing address space as kernel space is already mapped and I can simply use software interrupt?

Correct. You'll need to have the IDT mapped anyway to do the software interrupt, however keeping the kernel in each address space means your system calls can work directly on kernel functions, rather than waiting for a task switch (or worse, an address space switch).

I mean let int 0x81 in my system displays current time at left-top of screen, all i need to do is call set_interrupt(0x81,proc_time) inside my kernel where proc_time() uses print routine to display time. And in case of my application i will simply do int 0x81.

Exactly. However, typically implementations use a single interrupt with a system call number in EAX or something in order to support many more system calls than there are interrupts.

So it is all design choice, but what are the advantages of monolithic ( i mean mapping kernel in every address space )?

The wiki has an excellent discussion on Monlithic vs Micro vs Exo kernels: Kernels.

[Raven]

Thanks a lot dear!

One is yet to be cleared, i know it becomes irritating when u give your best answer and still a question pops.
But believe me it is again a confusion inside me not a question, so popping even on relevant answers is obvious.

If the kernel is in your application address spaces, you do not want to have your applications loaded in a location that could potentially overwrite your kernel. Say the application is linked to run at 0x100000, and your kernel is the same - when the application is loaded it'll want to overwrite the kernel. Not good!

You are correct but at the same time i fail to understand that by over writing you mean VIRTUAL address not physical?
Correct?
If this is correct then it is only possible if I have kernel address space sticked in user address space?

Hope this time i am correct.

I would suggest not having the application starting at 0x0 as, firstly, you can't have page faults on NULL pointer accesses, and secondly, if your kernel is at 0x100000 that limits you to 1 MB binaries that you can load. You also want to try to make things as extensible as possible, because it can be difficult to change things around later.

I got it!

Thanks a lot

[pcmattman]

Hi,

One is yet to be cleared, i know it becomes irritating when u give your best answer and still a question pops.
But believe me it is again a confusion inside me not a question, so popping even on relevant answers is obvious.

That's ok, I've been in your situation before

You are correct but at the same time i fail to understand that by over writing you mean VIRTUAL address not physical?

Correct - I do mean virtual addresses. Generally speaking all addresses you will talk about in your kernel after paging is turned on will be virtual, unless explicitly defined as physical.

Keep in mind that mapping the kernel address space into each process address space causes minor overhead (for example, if your kernel uses the space from virtual 0x0 to 0x400000 you're talking one page table - 4 KB of overhead for greater simplicity).

If this is correct then it is only possible if I have kernel address space sticked in user address space?

Yes, it is only possible if the kernel address space is present in the address space of the user process.

However, remember that you control loading so you can do checks to ensure that kernel memory won't be overwritten by the loaded process. As the kernel developer you can also provide the linker script (or your OS-specific toolchain, assuming you get to that stage) for which all applications must be linked with to run on your OS - which means you choose where they all get loaded to.

It's up to you whether you choose to keep the kernel out of all address spaces; just keep in mind that things like the IDT and (to a lesser extent) GDT need to be mapped to be used

I got it!

Awesome

[Raven]

Thanks a lot for your replies.
I think i got it, it time to implement.
Thanks a lot