Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- Subject: Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- From: Dean Reece <email@hidden>
- Date: Sun, 14 Dec 2008 20:33:39 -0800
On Dec 14, 2008, at 7:47 PM, John D. wrote:
On Sun, Dec 14, 2008 at 8:33 PM, Terry Lambert <email@hidden>
wrote:
You file a bug report with DTS.
OK, thanks.
This is good advice; if you need functionality that is not currently
provided via KPI, then asking for new KPI is the best way to go.
There is no guarantee that we will provide every requested KPI, but we
can't provide what we don't know is needed.
Apple cannot support every symbol in the kernel as an expansion point,
otherwise we would have to freeze the kernel as it is now and never
make any changes. Of course you don't need every symbol, just a
few... But if another hundred developers felt free to grab the one or
two extra symbols they need, we are left with an unsupportable mess,
and our customers (and our reputation) suffer when these kexts start
to panic after a software update.
The KPIs are our supported kernel interfaces; you are free to use
them for kernel extensions with a reasonable assurance of
compatibility with future versions of the OS. Circumventing our
linking mechanism to find private symbols you are interested in is not
acceptable practice for any product that will find its way into a
customer's hands.
While we don't claim to be perfect, we do work very hard to avoid
breaking the KPIs between releases. Any interface that is not
exported as a KPI is considered private to Apple and safe for us to
change at any time, even a dot release. Attempting to make use of non-
KPI symbols will almost certainly cause a bad user experience in the
future.
This is something we intentionally do not permit. A lot of
antivirus vendors were doing this and it broke our locking model.
So we provided KPI to let them intercept operations (that is called
"kauth" and you can find documentation on <http://
developer.apple.com>). If we change locking in the future, we won't
break them again.
Problem with kauth is that AFAIK it only let's you return 'deny' or
'pass' results. If, say, you want to return a ENOENT or special
errno to the syscall, it's not possible through kauth.
Most of the API used in unix_syscall isn't available in any KPI.
Yes. On purpose. I personally made the syscall table a private
symbol.
The problem is that it's a hassle for legitimate developers. People
trying to subvert the kernel might simply go and patch the IDT or do
something far more complex. Plus a memory search will yield sysent's
location easily.
It isn't a hassle for legitimate developers because they loose that
status as soon as they step outside our KPI space. Thus far, we have
not introduced strong protections to prevent developers getting at
things we don't export, but that may change if we see customer
problems resulting from such practice.
That leaves us with either patching its code on runtime (a hack,
which apparently isn't possible because that region isn't
writable; I'm not sure why kernel TEXT wouldn't be writable except
for security reasons I guess) or forgetting about implementing
anything around it.
We're mildly clever that way.
I was hoping we could vm_map_mprotect or alike the kernel text
temporarily. Do you know if this is feasible without resorting to a
non portable hack?
If you are considering this, you are already well within "non portable
hack" territory. Kernel text is made read-only because there is no
legitimate need to modify it. You may strongly want to modify kernel
text, but this is not supported and any attempts to do so are ill
advised.
I should add that everything I've said above only applies to Mac OS X
(the product). The Darwin Kernel is open and a completely reasonable
place to experiment when you need access to more kernel bits than KPIs
allow. This is why the first advice you received was to build your
own kernel.
Thanks,
- Dean
_______________________________________________
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