lkml.org 
[lkml]   [2003]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: FIXMAP-related change to mm/memory.c
>>>>> On Thu, 12 Jun 2003 19:07:40 -0700, Roland McGrath <roland@redhat.com> said:

Roland> The pte_user predicate was added just for this purpose. It
Roland> seems reasonable to me to replace its use with a new pair of
Roland> predicates, pte_user_read and pte_user_write, whose meaning
Roland> is clearly specified for precisely this purpose. That is,
Roland> those predicates check whether a user process should be
Roland> allowed to read/write the page via something like ptrace.

Roland> That's the obvious idea to me. But I have no special
Roland> opinions about this stuff myself. The current code is as it
Roland> is because that's what Linus wanted.

I considered a pte_user_read()/pte_user_write()-like approach, but
rejected it. First of all, it doesn't really help with execute-only
pages. Of course, we could add a pte_user_exec() and treat those
pages as readable, but that's not a good solution: just because we
want to make the gate page readable via ptrace() doesn't mean that we
want _all_ execute-only pages to be readable (it wouldn't make a
difference today, but I'm worried about someone adding other
execute-only pages further down the road, not being aware that
ptrace() would cause a potential security problem).

For ia64, I think we really want to say: if it's accessing the gate
page, allow reads. There is just no way we can infer that from
looking at the PTE itself.

Is there really a point in allowing other FIXMAP pages to be read via
ptrace() on x86?

--david
-
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 13:36    [W:0.041 / U:31.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site