site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On jeudi, novembre 23, 2006, at 08:14 PM, Michael Smith wrote: On Nov 22, 2006, at 6:04 PM, Michael Smith wrote: Stephane wrote: It turned out to be a copyin of a bigger size than required. I can see plenty of usage for this "science fiction" simulator thing. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Stephane wrote: When you do some bad things in your Kernel Extension (such as writing where you should not, reading a bit too far in buffers, etc...), should a Kernel Panic occur in your Kernel Extension or can it occur later? It depends on what you damage. If you read/write completely out of bounds, your code will fail. But if you destroy a pointer belonging to someone else, there is no way for the hardware/kernel to know a) that that's what you're doing, or b) to blame you when some other code attempts to use it. It could be cool if there was a Kernel simulator with memory protection... Protection of what? Read/write memory in the kernel map is freely writable by any code within the kernel; this is what being a "monolithic" kernel is all about. Well, since this would be a simulator, ideally you would be able to compile a specific version of a kext to run on it and you could tag specific data as protected. Given how much vilifiction Darwin has received for being a "microkernel" because we "all know" how inefficient they are, I see this rapidly becoming amusing. I just don't care about this. I'm just dreaming of a solution which would make it easier to track Kernel Panics. The positive output of this bug is that from what I've seen it's apparently way easier to reproduce a memory issue on an Intel Mac than on a PowerPC Mac. This email sent to site_archiver@lists.apple.com