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.
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)
While we are there, resolved another mystery: the unallocated port described
in the comment removed by this commit was in fact allocated by mach_task_pid().
have one parent yet (on Darwin, multiple parents are possible: the IOKit
seems to handle a graph more than a tree). Introfuction of a keyboard
driver parent for IOHIDSystem.
The kernel keymapping is still a big mystery.
Some initial support for IOHIDSystem. This gives us some pointer moves in X11
(not really related the the actual mouse movement, but this will come).
The darwin_iohidsystem_thread reads events from wscons, translates them
into IOHIDSystem events and wakes up the userland client with a notification.
To do this, I had to improve the void implementation of
io_connect_set_notification_port() to actually register something (I assumed
a single notification port, which makes some sense since only one process
seems to be able to open the driver)
Missing bits:
- we do not take event masks given by the process into account.
- the notification message has not been checked against Darwin
- events are badly translated
(not really related the the actual mouse movement, but this will come).
The darwin_iohidsystem_thread reads events from wscons, translates them
into IOHIDSystem events and wakes up the userland client with a notification.
To do this, I had to improve the void implementation of
io_connect_set_notification_port() to actually register something (I assumed
a single notification port, which makes some sense since only one process
seems to be able to open the driver)
Missing bits:
- we do not take event masks given by the process into account.
- the notification message has not been checked against Darwin
- events are badly translated
and make the stack and heap non-executable by default. the changes
fall into two basic catagories:
- pmap and trap-handler changes. these are all MD:
= alpha: we already track per-page execute permission with the (software)
PG_EXEC bit, so just have the trap handler pay attention to it.
= i386: use a new GDT segment for %cs for processes that have no
executable mappings above a certain threshold (currently the
bottom of the stack). track per-page execute permission with
the last unused PTE bit.
= powerpc/ibm4xx: just use the hardware exec bit.
= powerpc/oea: we already track per-page exec bits, but the hardware only
implements non-exec mappings at the segment level. so track the
number of executable mappings in each segment and turn on the no-exec
segment bit iff the count is 0. adjust the trap handler to deal.
= sparc (sun4m): fix our use of the hardware protection bits.
fix the trap handler to recognize text faults.
= sparc64: split the existing unified TSB into data and instruction TSBs,
and only load TTEs into the appropriate TSB(s) for the permissions.
fix the trap handler to check for execute permission.
= not yet implemented: amd64, hppa, sh5
- changes in all the emulations that put a signal trampoline on the stack.
instead, we now put the trampoline into a uvm_aobj and map that into
the process separately.
originally from openbsd, adapted for netbsd by me.
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
We try to map the console framebuffer through wsdisplay. It seems to work,
but we still need to _see_ something.
XXX Framebuffer size discovery is borken.
+ In ioframebuffer and iohidsystem:
More methods and more debug for io_connect_method_*
+ A few new IOKit mach traps.
return packet was wrong (port descriptor instead of VM area descriptor),
thus leading to SIGSEGV when calling IOKit's IOFBCreateSharedCursor().
Now this is fixed we can move forward again on graphic mode.
for the IOHIDSystem driver in Darwin. IOHIDSystem provides access
to user interface devices.
Communication between userspace and kernel is done through a shared
memory page. Our plan is to have a kernel thread waiting on wscons
events (for now it just does nothing), and have it feeding the
shared page.
