From: "David S. Miller" <davem@redhat.com>
To: davidm@hpl.hp.com
Cc: linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org
Subject: Re: can we make anonymous memory non-EXECUTABLE?
Date: Mon, 07 Jan 2002 22:02:08 -0800 (PST) [thread overview]
Message-ID: <20020107.220208.23012783.davem@redhat.com> (raw)
In-Reply-To: <200201080025.QAA26731@napali.hpl.hp.com>
In-Reply-To: <200201080025.QAA26731@napali.hpl.hp.com>
From: David Mosberger <davidm@hpl.hp.com>
Date: Mon, 7 Jan 2002 16:25:10 -0800
Also, as a practical matter, we currently have special hacks in the
ia64 page fault handler that are needed to work around performance
problems that arise from the fact that we map anonymous memory with
EXECUTE rights by default. Those hacks avoid having to flush the
cache for memory that's mapped executable but never really
executed. So clearly there are technical advantages to not turning
on EXECUTE permission, even if we ignore the security argument.
I assume this hack is "have a software EXECUTE bit, initially only
set the software one, when we take a fault on execute set the hardware
bit and maybe flush the Icache". If so, what is the big deal? :-)
What I'm wondering: how do others feel about this issue? Since x86
wont be affected by this, I'm especially interested in the opinion of
the maintainers of non-x86 platforms.
It seems to me that for portability reasons, dynamic code generators
should always do an mmap() call to ensure that the generated code is
executable. If we can agree on this as the recommended practice, then
I don't see much of a problem with not turning on the EXECUTE right by
default.
Opinions?
I think changing this behavior is going to silently break things on
many architectures. Secondly, I do not see any real gain from any
of this and my ports are those that have I-cache coherency issues :-)
Franks a lot,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2002-01-08 6:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-08 0:25 can we make anonymous memory non-EXECUTABLE? David Mosberger
2002-01-08 6:02 ` David S. Miller [this message]
2002-01-08 19:12 ` David Mosberger
2002-01-08 19:32 ` Albert D. Cahalan
2002-01-09 2:44 ` H. Peter Anvin
2002-01-09 2:49 ` Rik van Riel
2002-01-09 2:52 ` H. Peter Anvin
2002-01-09 11:32 ` Rob Landley
2002-01-09 19:47 ` Doug McNaught
2002-01-09 3:11 ` Alan Cox
2002-01-09 9:40 ` Erik Andersen
2002-01-08 13:23 ` Alan Cox
2002-01-08 19:15 ` [Linux-ia64] " David Mosberger
2002-01-11 5:49 ` David Mosberger
2002-01-10 1:04 ` Paul Mackerras
2002-01-10 3:40 ` David Mosberger
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=20020107.220208.23012783.davem@redhat.com \
--to=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=linux-ia64@linuxia64.org \
--cc=linux-kernel@vger.kernel.org \
/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