VM for device drivers? [LWN.net]

VM for device drivers?

Posted Sep 9, 2005 4:36 UTC (Fri) by xoddam (subscriber, #2322)
In reply to: 4K stacks for everyone? by mcelrath
Parent article: 4K stacks for everyone?

> gcc/libc can allocate more stack pages for userspace programs
> if needed, but why not the kernel?

A defining characteristic of kernel-space programming is that
you don't get the benefits of implicit memory protection.
Everything has to be done explicitly by the kernel itself.

It's possible in principle to give kernel-space tasks virtual
memory support, but it would open a big can of worms. If
you want deep recursion, do it in userspace.

As things stand the kernel-space page map is never changed
implicitly, and rarely explicitly. The prospect of giving
kernel tasks their own vm maps with holes to fit new pages
which are to be faulted in (from where?) when the stack
overflows is nightmarish! Performance and maintainability
are much, much more important than a growable stack.

If stack usage in kernel space isn't demonstrably finite
then the code is broken. The best solution is explicit
management of the resources (eg. using a queue) so that
the stack size ceases to be an issue.

(Log in to post comments)

VM for device drivers?

Posted Sep 11, 2005 1:14 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

The kernel uses virtual memory address translation today, and that's all that's required to do this kind of stack overflow protection. Make the stack one page and the page immediately after it invalid. A process tries to overflow the stack, and it gets oopsed.

However, I believe the point of 4K stacks is that there is a dirth of kernel virtual memory address space, so have 4K of usable addresses plus 4K of unusable obviates the 4K stack change.

To be robust like other OSes in this area, we'd have to go to some complex system with multiple kernel address spaces, and that probably would bring with it a pageable kernel.

VM for device drivers?

Posted Sep 13, 2005 1:17 UTC (Tue) by mcelrath (guest, #8094) [Link]

Dirth isn't a word. The word you wanted is dearth. (back at cha)

Anyway, one really needs an oops or panic if the kernel stack is overflowed. A previous poster said page faults in kernel space aren't detectable. You are proposing a 4k page at the end of the stack to check if the stack has overflowed. If there are no page faults in kernel space, then one has to check the stack-overflow page on every process switch? That seems expensive.

Then on the other hand this overflow page can probably be only one physical page, shared among all processes (and an oops or panic if ANY process writes it), and if a page fault isn't possible then the task switch could just do an

if(stack_overflow[0] != STACK_OVERFLOW_PATTERN) { oops }

e.g. just check the first byte. So overall it costs 1 cmp per task switch and 4k. Seems much better than silent stack overflows, and the possible security flaws that might come from them too...

VM for device drivers?

Posted Sep 13, 2005 16:07 UTC (Tue) by giraffedata (subscriber, #1954) [Link]

The kernel can and does detect page faults in kernel space. When the kernel tries to dereference a null pointer, the oops you see is due to the page fault. The same thing would work with the invalid page after the end of the stack (that's called a "guard page").

The earlier comment really meant that the kernel is not set up to handle a page fault in a virtual memory fashion -- i.e. do a pagein and continue as if nothing had happened.

But, unfortunately, the guard page has the same problem as 8K stacks -- requires an extra 4K per thread of kernel virtual memory address space and requires 2 contiguous virtual pages. There was a time when virtual address space was in abundant supply and we just worried about real memory, but today the reverse is often true.

VM for device drivers?

Posted Sep 20, 2005 20:19 UTC (Tue) by renox (subscriber, #23785) [Link]

>There was a time when virtual address space was in abundant supply and we just worried about real memory, but today the reverse is often true.

Well, only on 32 bit CPUs. The suggestion of adding guard page seems very valid to me, even if only for 64 bit CPUs: less crash or at least 'controlled crash' are always better.