VM for device drivers? [LWN.net]

VM for device drivers?

Posted Sep 11, 2005 1:14 UTC (Sun) by giraffedata (subscriber, #1954)
In reply to: VM for device drivers? by xoddam
Parent article: 4K stacks for everyone?

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.

(Log in to post comments)

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.