Re: Panic writing kernel memory?
Re: Panic writing kernel memory?
- Subject: Re: Panic writing kernel memory?
- From: Brian Doyle <email@hidden>
- Date: Thu, 24 Jan 2008 16:58:45 -0800
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