On Sat, Dec 31, 2011 at 05:44:31PM +0100, Reinoud Zandijk wrote: > On Fri, Dec 30, 2011 at 03:49:06PM +0100, Joerg Sonnenberger wrote: > > On Thu, Dec 22, 2011 at 08:22:17PM +0400, Valeriy E. Ushakov wrote: > > > On Thu, Dec 22, 2011 at 15:31:45 +0000, David Holland wrote: > > > > Consequently, the changes should be reverted, at least until the > > > > design has been gone through carefully. > > > > > > Seconded. > > > > Nothing happened yet? > > No, nothing happened yet... as an alternative i can see two basic NetBSD > additions: > > 1) have a system call > msyscall_block([lwp,] from_addr, to_addr) > that blocks from the specified range all system calls. Easiest to add. > > 2) have a system call > msetemul([lwp,] emulspec, from_addr, to_addr) > > that sets the emulation type for the specified memory range > allowing say linux libs to be linked to NetBSD libs > etc... can/could also be used to insert a system call block as > `emulation'. > > or we leave it as it is now...
I still don't see why you need or want anything that's specific to memory ranges. All you need is a single new emulation type where all the normal system call numbers cause a usermode trap (or whatever) and one extra reserved system call number that passes through to syscall() in the native emulation. The unmodified user programs you're running will never call this, so they won't step on it by accident and can remain unmodified. If you want to make sure programs running under the usermode kernel can't break out of it, that isn't good enough of course, but neither are all the other schemes you've been proposing. The other obvious approach is to add one or more new ptrace operations to provide proper/adequate/better support for intercepting system calls. This is probably a more useful facility in the long run, and it *can* be made leakproof, but it'll be more work. -- David A. Holland dholl...@netbsd.org
