Re: Panic writing kernel memory?
Re: Panic writing kernel memory?
- Subject: Re: Panic writing kernel memory?
- From: Terry Lambert <email@hidden>
- Date: Thu, 24 Jan 2008 17:16:20 -0800
Or you could just go to <http://developer.apple.com>, search for the
keywords:
exotic boot
and read articles #1 and #3, and save yourself a DTS ticket.
-- Terry
On Jan 24, 2008, at 4:58 PM, Brian Doyle wrote:
Fantastic!
Then I'll bid this thread adieu, do the homework you mentioned below
and start a ticket with DTS.
Thank you all for your time!
Brian
On Jan 24, 2008, at 4:49 PM, Garth Cummings wrote:
Hi Brian,
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.
Best,
--gc
On Jan 24, 2008, at 3:55 PM, Brian Doyle wrote:
Hi Garth,
Thanks for your reply!
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.
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.
Turns out moving bar to an
IOBufferMemoryDescriptory::inTaskWithPhysicalMask() and using
bcopy_phys() gets the job done.
Hooray for having the source to the O/S.
-b
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.
--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);
CFunctionPointer *foo = <some location containing a function
pointer>;
CFunctionPointer bar = <&some function>;
CFunctionPointer baz;
baz = *foo; // read ok
*foo = bar; // write panic
The panic log states "Memory access exception (1,0,0)".
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().
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
____________________________________________________________________
Garth Cummings email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
____________________________________________________________________
Garth Cummings email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden