public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Linus Torvalds <torvalds@osdl.org>,
	Hugh Dickins <hugh@veritas.com>, Nick Piggin <npiggin@novell.com>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Roland McGrath <roland@redhat.com>
Subject: Re: ptrace can't be transparent on readonly MAP_SHARED
Date: Thu, 15 Sep 2005 23:58:04 +0200	[thread overview]
Message-ID: <20050915215804.GN4122@opteron.random> (raw)
In-Reply-To: <20050915210931.GA14521@nevyn.them.org>

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.

      reply	other threads:[~2005-09-15 21:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-14 21:24 ptrace can't be transparent on readonly MAP_SHARED Andrea Arcangeli
2005-09-15  4:05 ` Nick Piggin
2005-09-15 13:18 ` Hugh Dickins
2005-09-15 15:12   ` Linus Torvalds
2005-09-15 15:47     ` Andrea Arcangeli
2005-09-15 16:13       ` Linus Torvalds
2005-09-15 16:23         ` Andrea Arcangeli
2005-09-15 16:34           ` Linus Torvalds
2005-09-15 16:51             ` Andrea Arcangeli
2005-09-15 17:52               ` Linus Torvalds
2005-09-15 18:09                 ` Andrea Arcangeli
2005-09-15 21:09                   ` Daniel Jacobowitz
2005-09-15 21:58                     ` Andrea Arcangeli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050915215804.GN4122@opteron.random \
    --to=andrea@suse.de \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@novell.com \
    --cc=roland@redhat.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox