Re: Kernel -> user boundary
Re: Kernel -> user boundary
- Subject: Re: Kernel -> user boundary
- From: Jim Magee <email@hidden>
- Date: Fri, 31 Jan 2003 01:51:22 -0800
On Thursday, January 30, 2003, at 05:42 PM, Marek Kozubal wrote:
I think this will do what you want.
http://www.java-internals.com/code/mig_in_kernel.html
Its a sample project on how to call MIG (Mach Interface Generator)
functions from a kext. It passes the mach port in via sysctl, however
you
can also do it other ways (like one of your private args to the mount
structure you pass mount()).
I won't even mention what I think of its syscall-patching mechanism
(except to say that it deserves to break at every opportunity).
More specifically on this point, it makes a few incorrect assumptions
about how the Darwin kernel works.
First off: There really are two modes within the kernel. There is the
kernel task mode - which is pretty much a full-blown Mach task for
kernel-resident threads to execute within. Then there is the kernel's
system/library executive mode - in which threads executes when they
trap into the kernel from other task contexts. Not all kernel services
work in both modes (many assume all callers are running in one mode or
the other), and some services simply behave differently when called
while running in the two modes.
Mach IPC is one of those things that behaves quite differently,
depending upon your kernel mode.
When you are running in the trap mode, Mach assumes you are intimate
with the implementation of Mach IPC (and may actually be assisting in
its implementation). So lots of validity checking is bypassed. Port
rights are held in limbo and not inserted into the kernel task's port
name space (these are known as "naked" rights in the code comments)
because Mach IPC assumes they are just on their way out to another
task. Likewise, out-of-line memory regions are not mapped into the
kernel's address space, but kept in vm_map_copy_t shorthand notation
for later mapping into the true receiver task. Heck, even the Mach
message headers are not converted into local perspective (local and
remote ports swapped) because the message is just assumed to be
"in-flight." Because of these distinctions, there are different IPC
primitives available (send-from-kernel, rpc-from-kernel, but no
"receive-from-kernel" because you aren't really a kernel thread at that
point).
Hooking up to receive trap-mode Mach IPC is even more difficult.
MIG can compensate for some of these differences if you tell it you are
running in the trap mode. But you have to deal with many of the
differences manually (you ARE a kernel programmer after all...).
In the example referenced here, they call mach_port_extract_right()
from within trap mode. That routine expects to be running in that mode
(which is good), but it expects to be doing its work on behalf of a
user task, not the kernel. Specifically, the extracted port right is
returned as a naked right - the caller is assumed to be a MIG-generated
server-side stub which will pack it into a (trap mode) message and send
that back out to user space. The port right is NOT inserted into the
kernel ipc_space (port name space). All the calls trying to manipulate
the kernel ipc_space are at best ineffective - leaking the naked port
rights, and therefore the associated memory (~100000 exits and this
thing will likely panic). Even worse, they are potentially more
dangerous - by accidentally deallocating a right that really was
inserted into the kernel's port name space by a kernel-bound thread
(and causing it to misbehave in less obvious ways).
See. None of this is easy. Is it? Programming unassisted in the kernel
is not for mere mortals.
That's why IOKit provides its own wrapper to all this that makes
requesting and sending notifications, both to your own user-clients and
to people listening on registry changes, relatively painless by
comparison.
As we develop facilities to support binary compatible extensions for
other KEXT models (like FS, and NKEs), we will be providing
notification mechanisms that match those models as well (with APIs that
feel and behave natively to those programming environments and yet are
catchable in other environments). This just takes quite a bit of time
and effort to do right. But without it, we don't feel like we have a
complete story and didn't want to have people trying the things that
will clearly get them in trouble (like above).
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.