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: Terry Lambert <email@hidden>
- Date: Sun, 14 Dec 2008 11:33:18 -0800
On Dec 14, 2008, at 9:08 AM, "John D." <email@hidden> wrote:
What would be the process to request a KPI to be made available? We
are talking about exporting a handful functions here.
You file a bug report with DTS.
Let's say I want
to emulate / write my own unix_syscall dispatcher for introducing some
process status tracking code or collecting stats or information about
registers or anything I need to do explicitly within the context of
the unix_syscall function, but implementing my own code along with it.
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.
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.
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.
-- Terry
A KPI that provides us with means of resolving a kernel symbol from a
kext would be extremely handy. I could understand that we want certain
symbols to be restricted, but this would let us solve many issues.
Whether it's from the running kernel or from a file on the root disk
is not really important.
John.
On Sun, Dec 14, 2008 at 5:50 PM, Terry Lambert <email@hidden>
wrote:
You are trying to do something for which there is no KPI.
You can ask for KPI (which you might not get) or you can build your
own
kernel. Basically you are asking us to not change what we consider
implementation details. We want them to be fungible so we can
implement more
efficient algorithms at a later date. Doing so will break your code.
-- Terry
On Dec 14, 2008, at 8:13 AM, "John D." <email@hidden> wrote:
That's just messed up. This is a KEXT, I can't force people to
rebuild
the kernel or patch it right away.
I guess I will have to search memory with a function hash of sorts,
but seems like a hack. I don't know why Apple decided to stop
exporting some really useful API (namely some kauth and proc
functions), plus restricting access to proc structure definitions by
providing a crippled public one.
My KEXT project is related with collecting statistics of processes
so
the non exported API is a bummer.
John.
On Sat, Dec 13, 2008 at 5:35 AM, Michael Smith <email@hidden>
wrote:
On Dec 12, 2008, at 8:15 PM, John D. wrote:
I'm working on a college project and I would like to access some
non-exported API. For example chgproccnt and
kld_file_lookupsymbol. I
want to be able to obtain a symbol address from a kernel
extension,
say, of the mach_kernel file. This could come handy but apparently
none of the useful API is available to extensions. Has anyone done
anything similar or can provide a suggestion to access
kld_file_lookupsymbol() without using static addresses (to avoid
version-specific builds, since Apple can change it anytime).
You will need to build your own kernel.
= Mike
_______________________________________________
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