public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: IA64 Kernel Question
Date: Tue, 08 Jan 2002 00:05:17 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590698805769@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805741@msgid-missing>

To followup on this issue: Robert tried the flush_memory() and the
program still didn't work.

I wrote:

>>>>> On Fri, 4 Jan 2002 14:36:50 -0800, David Mosberger <davidm@hpl.hp.com> said:

  David> The memory allocated by malloc() does indeed have execute
  David> permission turned on.  Linux does this for historical
  David> reasons.

This paragraph is correct in that it's describing the (traditionally)
intended behavior of Linux.  However, it turns out that there is a
platform-independent bug in the kernel which has the effect that the
first few bytes returned by brk() may not be executable.  The reason
this happens is that the ELF executable maps the data (and bss)
section with READ+WRITE rights only and the kernel doesn't turn on
EXECUTE right for the last such page, which usually contains the
initial break value.

So, the upshot of this is that for the time being, on ia64 you'll have
to do mprotect() to be certain that the memory returned by brk() is
executable.

I'm not sure what the long-term solution will be.  My inclination is
to break with tradition and make anonymous memory not exectuable by
default, but it's not clear whether this will be acceptable for all
platforms (x86 won't be affected because, there, the READ right
implies the EXECUTE right).  I'll follow up with a separate mail to
the LKML get a discussion going (I'll cc this list).

	--david


      reply	other threads:[~2002-01-08  0:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-04 22:36 [Linux-ia64] Re: IA64 Kernel Question David Mosberger
2002-01-08  0:05 ` David Mosberger [this message]

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=marc-linux-ia64-105590698805769@msgid-missing \
    --to=davidm@hpl.hp.com \
    --cc=linux-ia64@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