On Wed, Dec 9, 2009 at 3:06 PM, Scott James Remnant <sc...@ubuntu.com> 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()). -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
