![]() | ||||||||||
Messages in this thread |
torvalds@transmeta.com said: > But that is an address space that it should already has access to > through, since it created it in the first place (ie it would fall > under the normal "sys_mm_indirect()" case). Yes, and so it doesn't fall under ptrace. I think we're in violent agreement here. > The thing that I _really_ don't want to have is soem uncontrolled way > to generate accesses to existing "struct mm_struct"s, since that is > really dangerous from a security standpoint. Fine by me. UML has no need for manipulating pre-existing address spaces. > We could have a PTRACE_GET_MM_FD kind of thing for ptrace (and then > the gdb/tracer can use that to create mappings in the process), but > the reason I want that "hook" to be through ptrace itself is simply > that it's a known interface to control other unrelated processes. > > So if you create the MM's yourself, you can use the indirection > directly. But if you want to control your children or unrelated > processes, you use ptrace to get the hook. Yup. As far as UML is concerned, this is all fine. It has no need of a PTRACE_GET_MM_FD since it creates all address spaces itself, but other tools might. Jeff - 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/ | |||||||||
| Last update: 2005-03-22 12:31 [from the cache] ©2003-2008 | ||||||||||