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
