site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com exotic boot and read articles #1 and #3, and save yourself a DTS ticket. -- Terry 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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/lists%40balance-softwar... This email sent to lists@balance-software.com _______________________________________________ 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/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/gcummings%40apple.com ____________________________________________________________________ Garth Cummings gcummings@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ 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... Or you could just go to <http://developer.apple.com>, search for the keywords: On Jan 24, 2008, at 4:58 PM, Brian Doyle wrote: 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@apple.com This email sent to gcummings@apple.com This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com