Re: FIXMAP-related change to mm/memory.c

From: David Mosberger (
Date: Thu Jun 12 2003 - 21:16:37 EST

>>>>> On Thu, 12 Jun 2003 19:07:40 -0700, Roland McGrath <> 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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:35 EST