Re: CVS commit: src

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

Hi folks,

i am not subscribed to this mailing list so i only found this discussion when
someone pointed it out to me. I'll try to answer some questions raised about
it. There are also good feedbacks i'll incorporate. Please CC me on replies.

The code was indeed committed a bit short-tracked and i'm sorry for that. It
just happend that we were discussing it on chat a lot and all the lights were
green so to say and ppl. encouraged me to commit it, so i bypassed the mailing
lists yes where i should have queried them.

From the beginning of the usermode project, we struggled with the fact that
system calls in usermode's userland will go to the wrong kernel and get
confused, crash or mess things up. We've tried to tackle this with ptrace
constructions including the PTRACE emul stuf but that turned out to be a
dead-end since ptrace was never designed to allow redirection or interception
of system calls. On top of that, it also turned out to be agonizing slow.

The patch is thus indeed written, but surely not exclusively meant for
NetBSD/usermode support. With the patch, NetBSD/usermode can run native i.e.
unmodified binaries/sets/packages. Without the patch it can only run
explicitly compiled for code where all the system calls instructions (int
0x80/sysenter for i386/amd64) are replaced by undefined instructions UD1 and
UD2 (x86).

The patch is written to allow for multiple non-UVM flags to be attached to
mappings and allow the kernel to react on them. NetBSD/usermode uses this to
disallow system calls to be made from within mapped regions and get them
returned as illegal instructions so it can analyse and emulate the system
calls. To prevent every process to be scrutinized this way a process flag has
been introduced to mark if a process needs this check since the detection
involve acuiring a lock to walk the uvm map.

On the enhancing security argument, malicious source code could trigger
compiler bugs that allow for code to be modified or otherwise manipulated to
issue system calls where they shouldn't. Although it wouldn't nessiarily pose
a system security issue, it could be used for extracting info or for malicious
behaviour where with the patch it would simply bomb out.

As for the panic in sys_mmap(), as pointed out by Joerg and David Young, yes,
that should return a EOPNOTSUPP or an EINVAL. Panicing is indeed far too crude
and i'll change that.

Hope this answers most of your questions.

With regards,
Reinoud