Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Sun, Dec 18, 2011 at 10:34 PM, Christos Zoulas chris...@netbsd.orgwrote: Module Name:src Committed By: christos Date: Sun Dec 18 22:34:06 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-run: timer.cpp timer.hpp Log Message: Don't use antiquated BSD API's that require global variable, use posix timers instead. Interesting; didn't know about these. But what's the point of this change? It breaks OS X at least and does not fix anything AFAICT. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Mon, Dec 19, 2011 at 5:58 PM, Christos Zoulas chris...@zoulas.comwrote: On Dec 19, 5:00pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/external/bsd/atf/dist/atf-run | Interesting; didn't know about these. | | But what's the point of this change? It breaks OS X at least and does not | fix anything AFAICT. I am just trying to use modern POSIX API's to improve portability Well... modern has come to mean less portable in my book. (I like using modern APIs, but they tend to break grgrgr.) (and functionality in this case). For example, by using sigevent, one doesn't need to have global variables and he can pass the struct he wants to modify in the signal. In addition, one can use the monotonic clock, which is immune against time changes, and also use timespec which is more precise. Finally one is not limited to sigalrm for timers, but can send any signal. Thanks. I am really suprised that OS/X does not have them; I would have expected it to work on more systems than it does currently... I could only check with Snow Leopard and there is no timer_t there. I don't have access to Lion at the moment; when I do, I'll check again. If there is no support in it, I'll have to implement some conditional logic to use the new timers only if available (unless you have a better alternative?). If there is support, then I won't care about backwards compatibility. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Mon, Dec 19, 2011 at 8:32 PM, Christos Zoulas chris...@zoulas.comwrote: On Dec 19, 6:06pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/external/bsd/atf/dist/atf-run | I could only check with Snow Leopard and there is no timer_t there. I | don't have access to Lion at the moment; when I do, I'll check again. If | there is no support in it, I'll have to implement some conditional logic to | use the new timers only if available (unless you have a better | alternative?). If there is support, then I won't care about backwards | compatibility. Since it is my fault that I broke it, I will add a shim for OS/X that does not do anything fancy and implements the previous basic functionality that setitimer had. Could you check if this support exists in Lion first? If that's the case, I personally don't think it is a big deal. But thanks if you do that! -- Julio Merino / @jmmv
Re: CVS commit: src/sys
On Dec 21, 5:07am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: -- Subject: Re: CVS commit: src/sys | why? | i thought the reason of having this as a separate member was performance. All the code paths that use NBIO check bits in so_state... I would like to see the benchmark that proves this. christos
Re: CVS commit: src
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
Re: CVS commit: src
On Wed, 21 Dec 2011 16:47:49 +0100, Reinoud Zandijk wrote: 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. Why make this a memory-level property, and not a process-level property? If you want to proxy syscalls between host and usermode kernel, why make it exclusive to certain mem regions? I am probably missing something with the way usermode processes, usermode kernel host kernel interact. 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. That's the part I have trouble with. It looks like a weaker form of W^X (or PaX's mprotect), and I can't see the additional security benefits. Malicious code is free to trigger compiler bugs that can make calls to valid memory areas. If you manage to plant a int 0x80 in a MMAP_NOSYSCALLS executable region, just make it to a call __syscall. At the expense of a few more arguments, you will get the same result. 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. Waiting for mines :) -- Jean-Yves Migeon j...@netbsd.org
