[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/usermode (Was: CVS commit: src)
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
> 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
> 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
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
Main Index |
Thread Index |