On Sat, Dec 28, 2002 at 12:50:53PM -0800, Linus Torvalds wrote:
>
> On Sat, 28 Dec 2002, Jeff Dike wrote:
> >
> > > What are the semantics the host code wants/needs,
> >
> > 1 - Multiple address spaces per process
> > 2 - Ability to make a child switch between address spaces
> > 3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
> > on an address space which is not current->mm)
>
> Well, #3 falls under "ptrace()" as far as I'm concerned, I don't really
> want to expose things through /proc (or /dev, which is even _worse_).
>
> We used to have things that could be done with /proc/<pid>/mem, and it was
> a total security disaster. It was removed in the 2.3.x series because of
> that.
FWIW, GDB also would like to have #3. We can do without it; GDB
already supports calling functions in the inferior by a stack or code
trampoline, so we could just make the child call mprotect; but it would
be faster and simpler to have a ptrace op for it. HP/UX had, among
other things, TT_PROC_SET_MPROTECT and TT_PROC_GET_MPROTECT; I don't
think we have a system call equivalent to GET_MPROTECT right now.
Of course, without more comprehensive kernel support doing
protection-based watchpoints this way is murder for perfomance, almost
as bad as just doing it by single-stepping. You need to disable them
at every syscall entry, which means that you can't have multiple
threads running in userspace while one thread is in a syscall, or you
might miss a watchpoint event.
It would be ideal to have some way to set the permissions such that
accesses from inside the kernel succeeded and from userspace failed
(i.e. render it temporarily a kernel page; but not exactly; we'd want
things like "normally writeable; currently writeable by the kernel;
still currently readable by userspace" for a normal watchpoint).
I don't know if that's practical without impacting MM performance.
Suggestions welcome; I haven't really started to work on this yet
although it's creeping up my list of important debugger projects.
PowerPC MMUs have a mechanism that could be used for this but I don't
know if other architectures do.
-- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:13 EST