From: Scott Wood <scottwood@freescale.com>
To: paulus@samba.org
Cc: linuxppc-dev@ozlabs.org
Subject: Executing from readablee, no-exec pages
Date: Thu, 05 Jul 2007 16:55:32 -0500 [thread overview]
Message-ID: <468D68D4.4050704@freescale.com> (raw)
As revealed by the recent "Prevent data exception in kernel space"
patch, versions of glibc prior to 2.4[1] assume that, on powerpc32, they
can execute out of any readable mapping, regardless of whether it is
marked for execution. This happens in the elf_machine_load_address()
function.
To maintain compatibility with these versions, we could change the test
in do_page_fault() to include VM_READ as well as VM_EXEC on targets that
don't have a separate exec-bit in hardware (are there any powerpc mmus
that do?). However, Segher suggested on IRC that we may want to drop
compatibility with those old versions of glibc, and that I should seek
your input.
Personally, I'd rather stick the VM_READ in there, partially for selfish
reasons (our root filesystems are based on older glibcs), and because it
seems a little too soon to deprecate glibc 2.3, but also because in the
absence of hardware support, the VM_EXEC check will be nondeterministic,
kicking in only when the first fault for a page is to execute.
-Scott
[1] It's possible that there are other instances of this in 2.4 and that
the actual version is newer; I ran into obnoxious cross compilation
issues trying to try it. However,
<rant>
Glibc already has target-specific code/headers; if you need to know
something that you'd otherwise need a runs-on-the-target autoconf test
for, why not just stick it in such a target-specific header? In this
case, it was trying to figure out the size of "long double".
</rant>
next reply other threads:[~2007-07-05 21:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-05 21:55 Scott Wood [this message]
2007-07-05 22:38 ` Executing from readablee, no-exec pages Rodrigo Rubira Branco
2007-07-06 11:18 ` Johannes Berg
2007-07-06 13:36 ` Segher Boessenkool
2007-07-06 13:43 ` Johannes Berg
2007-07-06 13:24 ` Segher Boessenkool
2007-07-06 16:49 ` Scott Wood
2007-07-07 2:33 ` Benjamin Herrenschmidt
2007-07-06 14:42 ` David Woodhouse
2007-07-07 2:33 ` Benjamin Herrenschmidt
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=468D68D4.4050704@freescale.com \
--to=scottwood@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.