All of lore.kernel.org
 help / color / mirror / Atom feed
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>

             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.