Messages in this thread | | | From | David Mosberger <> | Date | Thu, 12 Jun 2003 19:16:37 -0700 | Subject | Re: 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/
| |