From: Roland McGrath <roland@redhat.com>
To: davidm@hpl.hp.com
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: FIXMAP-related change to mm/memory.c
Date: Thu, 12 Jun 2003 23:34:35 -0700 [thread overview]
Message-ID: <200306130634.h5D6YZ523894@magilla.sf.frob.com> (raw)
In-Reply-To: David Mosberger's message of Thursday, 12 June 2003 19:16:37 -0700 <16105.13317.608868.581471@napali.hpl.hp.com>
> 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.
The definition I gave was "should be readable by ptrace", and so it works
if that's how you categorize all execute-only pages. But...
> [...], 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).
Given that concern, I'll agree with your assessment.
> 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?
Currently, none are (because pte_user is only true of the vsyscall page).
For each individual arch, it seems reasonable enough to me to just have
special cases rather than testing the page tables. Rather than the code
now in #ifdef FIXADDR_START it could just call an arch_get_user_pages
function to check for magic user addresses without vmas.
Linus's suggested change is obviously the minimal change from what we have
now. But the arch_get_user_pages idea might be the more conservative
implementation compared to the status quo before my get_user_pages patch.
Thanks,
Roland
next prev parent reply other threads:[~2003-06-13 6:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-13 1:24 David Mosberger
2003-06-13 2:07 ` Roland McGrath
2003-06-13 2:16 ` David Mosberger
2003-06-13 6:34 ` Roland McGrath [this message]
2003-06-13 6:37 ` David Mosberger
2003-06-13 6:56 ` Roland McGrath
2003-06-13 7:15 ` Andrew Morton
2003-06-15 6:51 ` Anton Blanchard
2003-06-13 7:17 ` David Mosberger
2003-06-13 5:24 ` Linus Torvalds
2003-06-13 7:28 ` [BUG] " Riley Williams
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=200306130634.h5D6YZ523894@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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
all inboxes | Powered by JetHome®