Re: ptrace can't be transparent on readonly MAP_SHARED

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Sep 15, 2005 at 05:09:31PM -0400, Daniel Jacobowitz wrote:
> 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.

Well this is the first real life example that explains why having
the pte marked readonly might actually make a difference in practice
(debugging a segfault when overwriting .rodata makes sense), so I like
it a lot better and infact I now for the first time can see why it can
help.

.text is not going to change on-disk, so the coherency loss for the
pagecache is not significant but losing the readonly protection would
prevent the segfault to trigger and so it makes debugging more fancy.

It certainly wasn't related to any PROT_NONE.

Thanks.
-
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/