1) make sure Mach servers will not work on data beyond the end of the
request message buffer.
2) make sure that on copying out the reply message buffer, we will not
leak kernel data located after the buffer.
3) make sure that the server will not overwrite memory beyond the end
of the reply message buffer. That check is the responsability of the
server, there is just a DIAGNOSTIC test to check everything is in
good shape. All currently implemented servers in NetBSD have been
modified to check for this condition
While we are here, build the mach services table (formerly in mach_namemap.c)
and the services prototypes automatically from mach_services.master, just
as this is done for system calls.
The next step would be to fold the message formats in the mach_services.master
file, but this tends to be difficult, as some messages are quite long and
complex.
While we are here, try to tag machine dependent functions in header files.
also transformed darwin_ppc_*_state into mach_ppc_*_state, as this is
what they really are (COMPAT_DARWIN is on the top of COMPAT_MACH, not the
other way around)
are using lwp.
Enable kill -9 to kill parent thread waiting for its child.
Use upcallret instead of child_return for the newly created lwp.
Add debug messages for thread creation.
Thread creation are still broken...
1) rights should be shared by the threads within a process. While it would
be easier to handle this with the struct proc/struct lwp split, we attempt to
do this now by sharing the right lists. Because each right holds a reference
to struct proc, this might cause some problems later.
2) in pthread_exit, really exit the thread. Also reintialize the righ tlist to
make sure we will not destroy the parent's right list
3) rights can hold multiple permissions on a port (ie: send and receive). Fix th
is.
4) first attempt on right carried by messages. We still have to do rights carrie
d in the message body (complex messages).
This does not buy us new functionnality for now, because we still have to
discover how mach_init (which acts as a name server, enabling processes to
discover each other's ports) is able to receive messages from other processes
(this is a bootstrap problem, and the bootstrap port might be the place to
search).
While we are there:
- removed a lot of debug which is now available using ktrace.
- reworked message handling to avoid mutliple copyin/copyout of the
same data. ktrace of Mach message now uses the in-kernel copy of the
message instead of copying it from userland.
- packed mach trap handlers arguments into a structure to avoid modifying
everything next time we have to add an argument.
mach_port_move_member, mach_port_set_attributes, mach_task_set_special_port,
(none do anything)
Added mach_thread_create_running, which creates a new Mach thread. It
provides the register context of the new thread. We use it in a child
function provided to fork1(). The child function is machine dependent and
is not yet implemented for i386.
The new thread crashes quickly, but at least it starts.
Check for target buffer length, and fail if it is too short
Move mach_msg_trap and mach_msg_overwrite_trap to their own file
Remove some useless debug messages now we have ktrace
Remove __P()
manu