Supporting a GNU Hurd port?

John Moser john.r.moser at
Wed Dec 9 21:37:01 UTC 2009

On Wed, Dec 9, 2009 at 3:06 PM, Scott James Remnant <scott at> wrote:
> On Wed, 2009-12-09 at 14:48 -0500, John Moser wrote:
> That's certainly how things are supposed to work.  A lot of this kind of
> robustness comes from the requirement to support SMP systems, and make

I'm not talking about locking, I'm talking about a messed pointer
causing writes to memory in random places.

> For the last 2 releases?  The video driver has been an entirely separate
> userspace process from the kernel entirely, and demonstrates nicely why
> microkernels aren't a magic fix for this kind of problem.

No, a different 2 releases (actually, all of 2008).

> The reason your video card driver can crash your hardware is because
> your video card hardware can crash other bits of your hardware (which is
> most likely what's gone on here).

Actually, what was going on was part of the VIA video card DRM driver
in the kernel's execution space was copying buffers with a (void*)
type, but one of the functions took the (void*) type as (int) type.
On my architecture, (void*) was 8 bytes long and (int) was 4 bytes
long; this caused various strangeness.  There was also a DMA bug that
did the same thing, in that video driver.  In any case, instead of
copying things into video memory, multi-megabyte chunks of data got
copied over kernel memory.

> The usual microkernel religious argument is that by having drivers as
> separate processes from the kernel, they can't take out the kernel.  The
> usual monokernel religious argument is that it doesn't solve anything,
> because you still have to communicate between drivers, share resources,
> etc. and thus still hit the exact same deadlocks anyway.

We're not talking about deadlocks, we're talking about faults and
other misbehavior.  The kernel's been historically free of buffer
overflows, but quite full of off-by-one errors, stack overflows
(kernel stacks are 1-2 pages long and in random places, certainly not
burried in kernel code segments but they are next to other stacks for
other threads), NULL pointer dereferences, and the like.  Random
craziness does happen.

The typical microkernel argumets center more around drivers being able
to flat out crash-- enter a state where they've fallen into an
infinite loop, or attempted to access unmapped virtual addresses
(usually as a result of pointers getting screwed up by copying 30 megs
of data into a 30k buffer), or otherwise experienced a fatal case of
stupid -- and be re-initialized as separate programs.  Kernel drivers
do segfault, they just take down the whole operating system when they
do it; then we call panic() (or hopefully oops()).

More information about the Ubuntu-devel-discuss mailing list