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 19:07:40 -0700 [thread overview]
Message-ID: <200306130207.h5D27eH22519@magilla.sf.frob.com> (raw)
In-Reply-To: David Mosberger's message of Thursday, 12 June 2003 18:24:02 -0700 <200306130124.h5D1O2DT025311@napali.hpl.hp.com>
> Is it possible to constrain the FIXADDR range on x86/x86-64
> (FIXADDR_START-FIXADDR_TOP) such that the entire range is read-only by
> user-level?
The fixmap area is used for other kernel-only mappings for things that I
doubt should be exposed to users, not just user-accessible pages. At the
moment, the vsyscall page is the only user-accessible page in the fixmap
area. I wrote the get_user_pages change to be as generic as possible, so
it would do the right thing if other uses of the fixmap area were added.
Your patch makes the various other kernel-internal fixmap pages readable by
users, which is not right.
The pte_user predicate was added just for this purpose. It seems
reasonable to me to replace its use with a new pair of predicates,
pte_user_read and pte_user_write, whose meaning is clearly specified for
precisely this purpose. That is, those predicates check whether a user
process should be allowed to read/write the page via something like ptrace.
That's the obvious idea to me. But I have no special opinions about this
stuff myself. The current code is as it is because that's what Linus wanted.
Thanks,
Roland
next prev parent reply other threads:[~2003-06-13 1:54 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 [this message]
2003-06-13 2:16 ` David Mosberger
2003-06-13 6:34 ` Roland McGrath
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=200306130207.h5D27eH22519@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®