January 2008 - Darwin-kernel

Re: Panic writing kernel memory?
by Brian Doyle 25 Jan '08

25 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Fantastic! Thank you all for your time! Brian On Jan 24, 2008, at 4:49 PM, Garth Cummings wrote: Hi Brian, Best, --gc On Jan 24, 2008, at 3:55 PM, Brian Doyle wrote: Hi Garth, Thanks for your reply! Thanks again everyone, Brian On Jan 24, 2008, at 2:40 PM, Garth Cummings wrote: Hey Brian, On Jan 24, 2008, at 1:39 PM, Brian Doyle wrote: Answered my own question. Hooray for having the source to the O/S. -b --gc On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Then I'll bid this thread adieu, do the homework you mentioned below and start a ticket with DTS. DTS can get you everything you're looking for except for the boot- time password prompt. This is via the Boot≠Root mechanism introduced with the Intel-based Macs and expanded to include PowerPC- based systems in Leopard. It has similarities to the scheme you cooked up but it a supported means for booting filtered HFS volumes such as AppleRAID. There is a separate developer mailing list devoted to boot-time issues, called boot-dev. It's very low traffic but the folks who deal in this space are all members. You might want to look at the slides for last year's WWDC session 112 titled "From Power On to Login: Inside the Mac OS X Leopard Boot Process." The session goes into a fair amount of detail about Boot≠Root and DTS can help you with the rest. I'm trying to boot from an encrypted partition. When the system is running, Startup Disk sees the unencrypted partition and sets the boot device to its path normally. At boot time the firmware sees the encrypted partition, can't find a BootX/boot.efi file, and of course fails to boot. My solution to this is to append a tiny HFS+ partition to the end of the device that contains a custom BootX/boot.efi file responsible for password UI, creating a decrypting block driver, decrypting the target partition, and loading the real BootX/ boot.efi file. In order to make this work, I need to intercept an NVRAM boot- device write, store the target partition and replace the write with the path to the unencrypted bootloader partition. Conversely NVRAM boot-device read needs to do a switcheroo and return the intended target path. As I mentioned, I *could* just poll /options, but that approach is horrible for (at least) two reasons, 1) that I would need to poll frequently since a boot-device write is often followed by an immediate reboot and 2) the boot-device is hardly ever changed, so we'd be wasting zillions of CPU cycles. My hack-the-vtable approach, while admittedly far from wonderful, does give me the same functionality that subclassing would. I would *LOVE* to be able to do this in some sort of approved way that would not require a bunch of maintenance down the road but I'm at a loss as to a better approach. I should mention that if any of you Apple folks think this is something DTS would be willing to help me solve I'd gladly purchase a support incident and go through that channel. In that case please send me an offline email and I'll get the ball rolling. Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. Yeah, your approach is totally unsupported and is highly likely to break in the future. I hope this is for your own experimentation and not a commercial product. So what do you want to do when the boot device changes? Seems we should address the question from that angle in case it can lead to a hack-free solution. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to gcummings(a)apple.com This email sent to gcummings(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Garth Cummings 25 Jan '08

25 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Brian, Best, --gc On Jan 24, 2008, at 3:55 PM, Brian Doyle wrote: Hi Garth, Thanks for your reply! Thanks again everyone, Brian On Jan 24, 2008, at 2:40 PM, Garth Cummings wrote: Hey Brian, On Jan 24, 2008, at 1:39 PM, Brian Doyle wrote: Answered my own question. Hooray for having the source to the O/S. -b --gc On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… DTS can get you everything you're looking for except for the boot-time password prompt. This is via the Boot≠Root mechanism introduced with the Intel-based Macs and expanded to include PowerPC-based systems in Leopard. It has similarities to the scheme you cooked up but it a supported means for booting filtered HFS volumes such as AppleRAID. There is a separate developer mailing list devoted to boot-time issues, called boot-dev. It's very low traffic but the folks who deal in this space are all members. You might want to look at the slides for last year's WWDC session 112 titled "From Power On to Login: Inside the Mac OS X Leopard Boot Process." The session goes into a fair amount of detail about Boot≠Root and DTS can help you with the rest. I'm trying to boot from an encrypted partition. When the system is running, Startup Disk sees the unencrypted partition and sets the boot device to its path normally. At boot time the firmware sees the encrypted partition, can't find a BootX/boot.efi file, and of course fails to boot. My solution to this is to append a tiny HFS+ partition to the end of the device that contains a custom BootX/boot.efi file responsible for password UI, creating a decrypting block driver, decrypting the target partition, and loading the real BootX/boot.efi file. In order to make this work, I need to intercept an NVRAM boot- device write, store the target partition and replace the write with the path to the unencrypted bootloader partition. Conversely NVRAM boot-device read needs to do a switcheroo and return the intended target path. As I mentioned, I *could* just poll /options, but that approach is horrible for (at least) two reasons, 1) that I would need to poll frequently since a boot-device write is often followed by an immediate reboot and 2) the boot-device is hardly ever changed, so we'd be wasting zillions of CPU cycles. My hack-the-vtable approach, while admittedly far from wonderful, does give me the same functionality that subclassing would. I would *LOVE* to be able to do this in some sort of approved way that would not require a bunch of maintenance down the road but I'm at a loss as to a better approach. I should mention that if any of you Apple folks think this is something DTS would be willing to help me solve I'd gladly purchase a support incident and go through that channel. In that case please send me an offline email and I'll get the ball rolling. Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. Yeah, your approach is totally unsupported and is highly likely to break in the future. I hope this is for your own experimentation and not a commercial product. So what do you want to do when the boot device changes? Seems we should address the question from that angle in case it can lead to a hack-free solution. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to gcummings(a)apple.com This email sent to gcummings(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Brian Doyle 25 Jan '08

25 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -b On Jan 24, 2008, at 4:10 PM, Michael Smith wrote: Brian, = Mike On Jan 24, 2008, at 3:55 PM, Brian Doyle wrote: Hi Garth, Thanks for your reply! Thanks again everyone, Brian On Jan 24, 2008, at 2:40 PM, Garth Cummings wrote: Hey Brian, On Jan 24, 2008, at 1:39 PM, Brian Doyle wrote: Answered my own question. Hooray for having the source to the O/S. -b --gc On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drivers%40mu.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I considered this approach, but if the power fails the system will become unbootable. You should have no trouble doing this at shutdown time; either in your driver or in response to SIGTERM in a userland daemon during shutdown. There's no need to constantly track the boot device while the system is up and running that I can see; it's only when you're about to boot from one of your partitions that it matters. I'm trying to boot from an encrypted partition. When the system is running, Startup Disk sees the unencrypted partition and sets the boot device to its path normally. At boot time the firmware sees the encrypted partition, can't find a BootX/boot.efi file, and of course fails to boot. My solution to this is to append a tiny HFS+ partition to the end of the device that contains a custom BootX/boot.efi file responsible for password UI, creating a decrypting block driver, decrypting the target partition, and loading the real BootX/ boot.efi file. In order to make this work, I need to intercept an NVRAM boot- device write, store the target partition and replace the write with the path to the unencrypted bootloader partition. Conversely NVRAM boot-device read needs to do a switcheroo and return the intended target path. As I mentioned, I *could* just poll /options, but that approach is horrible for (at least) two reasons, 1) that I would need to poll frequently since a boot-device write is often followed by an immediate reboot and 2) the boot-device is hardly ever changed, so we'd be wasting zillions of CPU cycles. My hack-the-vtable approach, while admittedly far from wonderful, does give me the same functionality that subclassing would. I would *LOVE* to be able to do this in some sort of approved way that would not require a bunch of maintenance down the road but I'm at a loss as to a better approach. I should mention that if any of you Apple folks think this is something DTS would be willing to help me solve I'd gladly purchase a support incident and go through that channel. In that case please send me an offline email and I'll get the ball rolling. Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. Yeah, your approach is totally unsupported and is highly likely to break in the future. I hope this is for your own experimentation and not a commercial product. So what do you want to do when the boot device changes? Seems we should address the question from that angle in case it can lead to a hack-free solution. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to gcummings(a)apple.com This email sent to drivers(a)mu.org This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Brian Doyle 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Garth, Thanks for your reply! Thanks again everyone, Brian On Jan 24, 2008, at 2:40 PM, Garth Cummings wrote: Hey Brian, On Jan 24, 2008, at 1:39 PM, Brian Doyle wrote: Answered my own question. Hooray for having the source to the O/S. -b --gc On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I'm trying to boot from an encrypted partition. When the system is running, Startup Disk sees the unencrypted partition and sets the boot device to its path normally. At boot time the firmware sees the encrypted partition, can't find a BootX/boot.efi file, and of course fails to boot. My solution to this is to append a tiny HFS+ partition to the end of the device that contains a custom BootX/boot.efi file responsible for password UI, creating a decrypting block driver, decrypting the target partition, and loading the real BootX/boot.efi file. In order to make this work, I need to intercept an NVRAM boot-device write, store the target partition and replace the write with the path to the unencrypted bootloader partition. Conversely NVRAM boot-device read needs to do a switcheroo and return the intended target path. As I mentioned, I *could* just poll /options, but that approach is horrible for (at least) two reasons, 1) that I would need to poll frequently since a boot-device write is often followed by an immediate reboot and 2) the boot-device is hardly ever changed, so we'd be wasting zillions of CPU cycles. My hack-the-vtable approach, while admittedly far from wonderful, does give me the same functionality that subclassing would. I would *LOVE* to be able to do this in some sort of approved way that would not require a bunch of maintenance down the road but I'm at a loss as to a better approach. I should mention that if any of you Apple folks think this is something DTS would be willing to help me solve I'd gladly purchase a support incident and go through that channel. In that case please send me an offline email and I'll get the ball rolling. Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. Yeah, your approach is totally unsupported and is highly likely to break in the future. I hope this is for your own experimentation and not a commercial product. So what do you want to do when the boot device changes? Seems we should address the question from that angle in case it can lead to a hack-free solution. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to gcummings(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Michael Smith 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 24, 2008, at 3:20 AM, Brian Doyle wrote: What processing are you trying to do? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… As you've correctly surmised, I'm trying to patch the vtable of a class that isn't mine and that I can't inherit from (IODTNVRAM/ AppleEFINVRAM). My intent is to be notified when setProperty() is called on IODeviceTree:/options so that I can do some processing when the boot device changes. Why do you have to do it every time the boot device changes? Why can't you postpone it until system shutdown time when there is no longer an opportunity for it to change again? (This is the only time the physical NVRAM is actually written anyway.) Since you have no way to reliably affect the boot device selection, and no guarantee whatsoever that the system will boot from the device set to be the boot device in NVRAM, you can't be doing this from a "security" perspective. This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to debug VM trouble?
by Michael Smith 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 24, 2008, at 1:31 PM, Michael Crawford wrote: We were suspecting for a while that the bug was in the OS X kernel. We're going to do whatever it takes to find the real source of trouble. If it turns out that we later conclude that it is in fact in Apple's code, I'll be sure to file a bug report and post the number to this thread. Michael, = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… If you have a reduced version of your tool that you can attach to the bug, I'm sure that will help. As a general rule, kernel memory starvation should not result in system calls that could be deferred instead returning errors, although per Rick's thread a while back on this list it is a nontrivial thing to get the right behaviour in the face of the heavy layering within the kernel. What I'm saying is that the miscompares you're seeing may well be a tool bug, but the filesystem operations returning ENOMEM feels to me like a kernel bug, and you should file accordingly. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Garth Cummings 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hey Brian, On Jan 24, 2008, at 1:39 PM, Brian Doyle wrote: Answered my own question. Hooray for having the source to the O/S. -b --gc On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. Yeah, your approach is totally unsupported and is highly likely to break in the future. I hope this is for your own experimentation and not a commercial product. So what do you want to do when the boot device changes? Seems we should address the question from that angle in case it can lead to a hack-free solution. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to gcummings(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Brian Doyle 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Answered my own question. Hooray for having the source to the O/S. -b On Jan 24, 2008, at 1:09 AM, Brian Doyle wrote: Hello, I've written a kext which, quite simply, does this: typedef void (*CFunctionPointer)(void); baz = *foo; // read ok *foo = bar; // write panic The panic log states "Memory access exception (1,0,0)". Can anyone help? I would certainly appreciate it! Thanks, Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwa… This email sent to lists(a)balance-software.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Turns out moving bar to an IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using bcopy_phys() gets the job done. ps. - I still understand "why I shouldn't do this" but I have yet to come up with a better approach that doesn't require polling. CFunctionPointer *foo = <some location containing a function pointer>; CFunctionPointer bar = <&some function>; CFunctionPointer baz; I'm guessing the memory I'm trying to write to has VM_PROT_WRITE disabled, but I'm not sure how to verify that (vm_region() on the address foo causes a different panic, namely a null-pointer dereference crash down in vm_map_lookup_entry()). I've noticed that when I'm two-machine debugging with gdb I can set the value *foo directly from the gdb command line with no problem. This is all well-and-good, but I need to be able to replace this function pointer from my kext. I gave vm_protect() a try but that crashed too, in the same place as vm_region(). This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to debug VM trouble?
by Michael Crawford 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=07JwfhnH74R+7zLzvnk2p2CLUT8hpOrgi+IW/sT45f4=; b=vRihqueIDaj9e+dox7UhKBCAs/TaXwvvNCRuzNy1+Wq2d1/0XQ69hAMH2uHnKusH8Yryv4LFsDQ8ZTZzs/HeIE1MJml4ewtaRSGu3RhKYaqlSs3bRp5R+NoRJ72eTGqJHNdEc2t42AbPM1ITyOBsbJEloBjilvCEakfYWa9euUM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rlLmHbasOi4Nl6wAEX0fPPxYzKX1l9ylpWdrdMxtPxAunpljWlnhp0YJAeLHQp1KKhZg6IRg2QTvDMGmexR2QTmJMXFOPT0fiWvF9KfvT5XNh7VOBhqH0pWQBhbF/+7dmzKZYJXMVm3Fsq4MEvQ4RKJsqEfvr8jTShSkLLpkOKs= We are now thinking that the error we're seeing with our disk test tool may actually be a bug in the tool. One of my coworkers is now inspecting its source to see if he can find the problem. We have a tool to test our RAID controllers that spawns some threads that each write a file, then reads it back to check that what it gets back is what it wrote. If we spawn a lot of threads, each writing very large files using large memory buffers, and let the tool run for a day or two, eventually there will be a miscompare. This doesn't happen with smaller files, fewer threads, or with more memory installed in the Mac. But when it does, there will also be a bunch of messages in the system.log from other programs such as daemons, complaining for example of getting ENOMEM from write() system calls. Our theory is that we're running the kernel out of memory, so that it eventually returns errors to our own system calls, but we don't check the error code properly. The data is then either not read or not written because the call failed. While I do have to let the tool run for a long time, I am also able to stimulate the bug using drives hooked to the motherboard SATA controller in my dual G5, without our PCI card or device driver being involved. Unfortunately, our test tool has grown organically as it was ported from platform to platform over the years - so it's not actually easy to spot any problems. But such legacy code is likely the source of our trouble. We were suspecting for a while that the bug was in the OS X kernel. We're going to do whatever it takes to find the real source of trouble. If it turns out that we later conclude that it is in fact in Apple's code, I'll be sure to file a bug report and post the number to this thread. Thanks for all your advice. Mike Crawford mdcrawford at gmail dot com http://www.geometricvisions.com/ <-- Creative Commons Music Downloads _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Panic writing kernel memory?
by Brian Doyle 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Don't do that. Mike is right. Don't do that. David Can either of you offer a better solution? -b _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… = Mike This email sent to site_archiver(a)lists.apple.com

1 0