> Normal programs shouldn't be able to run in kernel space. And it should be > able to recover from a badly written program. That's the purpose of memory > protection that normal users are interested in.
Microsoft Word won't bring about a bluescreen by any fault of it's own, simply because it is a normal program. When Word dies, Windows brings up that little grey requester with the bitchload of numbers in it (nowadays it's the "do you want to send your soul, base64 encoded, to Microsoft?"). The SOLE candidate for bluescreens, kernel panics, whatever, is a buggy driver or kernel process, perhaps one which doesn't implement a feature and decides to bail because it's supposed to be pretty important functionality. Perhaps an interrupt fired while it was handling it's own interrupt handler, a bad thing to happen. Windows contains good portions of it's graphics and networking systems embedded in the kernel for speed purposes. But they're heavily abstracted and most drivers have ABSOLUTELY NO NEED to go into kernel mode for their own purposes. At the point they do: you almost invite a bluescreen. The WDM architecture solves all this anyway. > How did you mean that you can write a BSD program that craches the kernel > without exploiting a kernel bug? Drivers run in kernel space. Write a buggy driver, crash the OS. Write a kernel process in the Linux kernel (perhaps you could hack the packet filter..) and BOOM-BANG-A-BANG. Kernel panic. What happens if the swap disk is corrupted at the point you're supposed to be reading from? BANG! Kernel panic, bluescreen, and so on ;) Windows no better or worse than any other OS. -- Matt Sealey <[EMAIL PROTECTED]>
