Re: ptrace can't be transparent on readonly MAP_SHARED

[Daniel Jacobowitz <dan@debian.org>]

On Thu, Sep 15, 2005 at 08:09:28PM +0200, Andrea Arcangeli wrote:
> On Thu, Sep 15, 2005 at 10:52:14AM -0700, Linus Torvalds wrote:
> > And the PTRACE_POKE is _exactly_ the same thing. There's _zero_ 
> > difference. The fact that PTRACE_POKE _changes_ the data instead of just 
> > reading it doesn't change anything at all - the fact that data got changed 
> > in NO WAY invalidates the fact that processes might still depend on 
> > getting a SIGSEGV.
> 
> And this process may as well depend to see the on-disk changes that
> other threads are doing on the shared memory, and that will break
> regardless of what Linus changes in the kernel.
> 
> You also didn't make up any useful example where _writing_ (not reading
> like in your example) was involved. Your example is totally offtopic,
> since it only involved reading as far as I can tell.
> 
> I can't imagine where writing to a PROT_NONE is actually useful.

Well, you won't like this example any better, then, but this was a
frequently reported GDB bug for a while:

const int x;
int main()
{
  *x = 1;
  return 0;
}

x goes in rodata -> text segment -> on the same page as main.  If you
run to main in GDB, the page becomes writable.  The store doesn't
crash.  If you run it out of GDB, it crashes.

Sure, the trivial example's uninteresting.  But you can construct a
larger example with, say, *foo() = x replaced by *foo = x.  That's not
legal in C for a function foo, of course.  But you could probably
manage it in some other language, or in asm.  So you debug right around
where you're getting a crash in your application, and it doesn't crash.

Ptrace needs to be as unintrusive as possible.  Having the page COW
unexpectedly is a lot less bad than having it COW _and_ remain
writable.

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
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/