Re: ptrace can't be transparent on readonly MAP_SHARED

[Linus Torvalds]

On Thu, 15 Sep 2005, Andrea Arcangeli wrote:
>
> On Thu, Sep 15, 2005 at 09:34:12AM -0700, Linus Torvalds wrote:
> > If you think the data is wrong, then you are arguing against the COW. Yes, 
> > the COW will make the data "wrong", but you can't escape that. That's what 
> > a "write" by ptrace does.
> 
> My point is that exactly because this is the wrong page with the wrong
> data with the wrong ptrace usage, these kind of things will happen in a
> very controlled environment

I disagree.

_The_ most common use of PTRACE_POKE is debugging. And gdb doesn't "know" 
what the process is doing.

> I don't see why the kernel should bother to fix an unfixable case.

I don't see why you argue against trying to do our best.

Let me tell you why you're wrong, with a real-life example.

I debugged "sparse" with making all de-allocations turn the page 
protections to PROT_NONE. 

That's absolutely _wonderful_. It means that when the process does a bad
access, I get a SIGSEGV (and the memory hasn't been allocated to something
else, as would happen if I had just munmapped it). And when debugging 
this, I could _see_ what the old contents were - because PTRACE_PEEK 
could punch through the protections - so I had lots of extra information. 

For example, I could look at the free'd data to see where it came from, 
because the free'd data actually contained pointers to other stuff, giving 
me a very good view of _what_ had gotten free'd too early.

Now, in this case, a SIGSEGV was always fatal, but the fact is, some 
applications actually catch it, and do their own VM management. It's rare, 
but it definitely exists. So should the fact that I looked at the data 
make that the protections changed? HELL NO! My debugger may have looked at 
it, but that doesn't invalidate the notion that the program still expected 
to get a SIGSEGV on it.

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.

If you want to change permissions, then add a PTRACE_MPROTECT thing or 
something, and teach gdb to use that. But if you don't want to change 
permissions, then you shouldn't change permissions.

Now, if you have a technical reason why "maybe_mkwrite()" needs to go 
away, then that's a different thing. BUT IT HAS NOTHING TO DO WITH THE 
FACT THAT WE LOOKED AT OR CHANGED THE DATA!

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/