Paging Idea for a Microkernel (not sure if it would work)

[chrissacchi]

Note: This may be a bad idea, but I'm not sure... it should *ONLY* work for a microkernel or a similar design...

Idea:

Let's say you have a page directory initialization function that creates a map of the current address space, giving a pointer that can be moved to CR3. What if the page directory for user processes does not map the kernel address space, AKA marking it as not present? On the event of a task switch or a software interrupt, for example, the task switch IRQ handler or the interrupt handler are already placed into user memory, running at CPL=0 when called so they can re-map the kernel-space as present. Once everything needed to be executed in the kernel and user-mode servers has run, the kernel remaps CR3 to not include kernel space every level of the software interrupt or task switch. While the kernel and the servers are communicating (IPC), they don't switch CR3 until they are *completely* finished (no one wants to make the system slower by adding too many CR3 swaps for no good reason).

This would involve work in the kernel to re-map many functions outside of it, which is a good thing for a microkernel design. Of course, there would need to be adequate memory protection for userspace as well.

This is, of course, a theoretical concept at the moment.

[Boris]

So basically you want a " iceberg" design where only the tip of it is permanently mapped ( for interrupts & syscalls )
This can work . But what benefit does it brings you ?
Do you want to save TLB space until the next syscall ?

The only reason I would do that is to be able to hook/mock / sandbox syscalls for a given process.

[mariuszp]

Then every single address space (of every process) would need to include those interrupt handlers, and since they're in userspace, they could easily be corruped.

My solution to this is that there is only one paging structure per CPU; i.e. there is only one value for CR3 on each CPU, and is never changed. I only change the first PDPT depending on process, which gives 512 GB of virtual userspace memory per process, and that is certainly enough, and avoids the overhead of copying all kernel page structure into every address space. It also avoids the security flaw I mentioned above.

[onlyonemac]

Sounds interesting from a security point of view - only privileged (and presumably trusted) code can enter the kernel address space.

[Brendan]

Hi,

Sounds interesting from a security point of view - only privileged (and presumably trusted) code can enter the kernel address space.

Not really - the "always present" part of the kernel would have to enable/map the majority of the kernel every time the kernel needs to do anything; which means the only time the "temporarily not mapped" part of the kernel would actually be "not present" is when you're running at CPL=3 and wouldn't be able to touch it if it was present.

Essentially; it probably won't be any better for security than a traditional micro-kernel. It'll just be much much slower due to frequent "kernel TLB flush" problems.


Cheers,

Brendan