Re: IOKit KEXT Questions
Re: IOKit KEXT Questions
- Subject: Re: IOKit KEXT Questions
- From: Terry Lambert <email@hidden>
- Date: Wed, 15 Aug 2007 20:24:37 -0700
On Aug 15, 2007, at 5:40 PM, Matt Burnett wrote:
You didnt answer my question, and you jumped to conclusions. I all
ready have functioning code to arbitrarily hook kernel functions. I
didn't ask for help on how to do this, i just asked if there are any
IOKit classes that implement features similar to mprotect/vm_protect,
I didn't answer because I'm not the best person to answer this
particular question, and you are actually unlikely to find them on the
"dev" list instead of the "kernel" list. Here is my best answer:
No, there are not.
"Unsupported" exports vm_protect, but to get the right map identifier
you would have to go through other unsupported exports in order to
find the right map for the task involved, and by the time you are down
in the IOKit, if you are on a work loop or another thread, or the
operation is an AIO operation being proxied on behalf of a user space
process, or a request from an NFS client, etc., the task you get will
not be the task that initiated the action. If so, you will not be
able to make the call without information which is lost by the time
the call to your code happens. This will also fail from 64 bit code,
which requires the use of mach_vm_protect() instead of the 32 bit
vm_protect() to represent address space ranges that span or which are
above the 4G 32 bit address space limit.
Your best bet is to deal with this from user space instead.
and why IOKit based KEXTs have issues resolving symbols in the kernel.
Because we intentionally made it difficult to get at things we think
will probably change over time, to try and ensure forwards binary
compatibility for our KEXT developers and our users; when everything
Just Works, that's best for everyone. You can't resolve many symbols
because we __private_extern__'ed the sysent[] table members because
people were hooking them (predominantly for antivirus software).
These hooks don't work long term, and tend to break between software
updates because these functions are not KPI; they are off limits for
use in code you want to work after a software update, or between major
releases.
For example, we've changed the credential structure reference model
several times in software updates in order to deal with a number of
developer issues, so anything that attempts to deal with a cached
reference to a cred (for example, creating a process via fork+execve)
that used old code would suddenly be implemented incorrectly, if the
code we intended was replaced by a third party with a copy from
previously published versions of the code.
You can always link your KEXT against the entire kernel, which gets
you all the non-private symbols (private ones were stripped by the
linker when Mach, BSD, and IOKit were linke to create mach_kernel), at
the cost of your KEXT not working each time there is a software
update. This will more or less ensure that you at least had
opportunity to update to the most recent code base before you changed
the version dependency string.
- I can still use mprotect/vm_protect
Please do so (see above); if someone else jumps in with a better
answer, feel free to take their answer instead.
- For the symbols issue, i can at the very worst use some script
hackery to resolve the symbols in user space and transfer their
addresses to my KEXT.
Expect that this could break in software updates.
I know there are tables in the kernel where i could resolve the
symbols manually as well.
Incorrect; these tables are all in user space after the message
"Jettisoning kernel linker" is emitted to the console, very early in
the boot process. All KEXT linking not coming out of preloading
occurs in user space vs. the supported KPI symbol sets, and the symbol
tables aren't mapped into kernel memory along with the rest of the
KEXT or mach_kernel sections.
I would like to remind you that hurling insults at me such as
"unscrupulous" (definition: having or showing no moral principles;
not honest or fair) does nothing other than provoke me to release a
SDK to the public which would allow people to hook kernel functions.
I was specifically referring to the act of overwriting kernel function
entries, and the potential for misuse/abuse, and the high likelihood
that the system would become unstable, if not immediately, then most
probably as soon as you installed an update. FWIW, the already
announced Leopard DTrace facility depends on being able to do this
type of thing on its own, and would more or less stomp any code you
put in its way.
If you can't accomplish what you need to accomplish within the
constraints of KPI, please contact DTS to request additional KPI.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden