wrong on the semantic front; the spurious wakeup confuses Darwin's gdb.
Allow vm, task and thread operations on remote processes. The code to pick up
the remote process is in mach_sys_msg_trap(), so that any Mach service can
use it.
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.
copyin() or copyout().
uvm_useracc() tells us whether the mapping permissions allow access to
the desired part of an address space, and many callers assume that
this is the same as knowing whether an attempt to access that part of
the address space will succeed. however, access to user space can
fail for reasons other than insufficient permission, most notably that
paging in any non-resident data can fail due to i/o errors. most of
the callers of uvm_useracc() make the above incorrect assumption. the
rest are all misguided optimizations, which optimize for the case
where an operation will fail. we'd rather optimize for operations
succeeding, in which case we should just attempt the access and handle
failures due to insufficient permissions the same way we handle i/o
errors. since there appear to be no good uses of uvm_useracc(), we'll
just remove it.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
request a mapping at fixed address, overlaying previously existing mappings.
The overlay is done by unmapping (sys_munmap) before mapping at fixed
location. This makes XDarwin able to link and run.
There are two new mach traps:
mach_vm_make_memory_entry, mach_host_get_io_master. Now we need to find
the documentation to understand what they are supposed to do.
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.
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()
is already used, we want to remap to another place. The vmcmd must be
completely rebuild, else things does not work as expected, as the vmcmd has
been modified by the first mapping attempt.
the binary on the second launch.
In mach_vm_map, hack in a failure so that we fail exactly like Darwin when
mapping a page at address 0
Add vm_allocate trap
grant