linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Alan Modra <amodra@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: ppc64 sbrk returns executable heap in 32-bit emulation mode
Date: Mon, 16 May 2016 10:51:38 +0200	[thread overview]
Message-ID: <998d04cd-6653-7029-51a6-2540ec7dd798@redhat.com> (raw)
In-Reply-To: <20160516062425.GA24091@bubble.grove.modra.org>

On 05/16/2016 08:24 AM, Alan Modra wrote:
> On Thu, May 12, 2016 at 03:41:09PM +0200, Florian Weimer wrote:
>> We noticed that on ppc64, the sbrk system call in the 32-bit subsystem
>> returns executable memory.  I assume it is related to this, in
>> arch/powerpc/include/asm/page.h:
>>
>> /*
>>   * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
>>   * and needs to be executable.  This means the whole heap ends
>>   * up being executable.
>>   */
>> #define VM_DATA_DEFAULT_FLAGS32 (VM_READ | VM_WRITE | VM_EXEC | \
>>                                   VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>>
>>
>> What is the rationale for this?  This comment must be *really* old,
>
> I think the comment is just plain wrong.  ppc32 needs an executable
> stack because it builds trampolines on the stack to support calling
> nested functions.  I presume that's why the heap is executable.  (If
> I'm wrong about heap+stack needing the same protection then I can't
> think of any reason to require an executable heap.)

But the stack is *not* executable.  The program is marked correctly with 
GNU_STACK:

   GNU_STACK      0x000000 0x00000000 0x00000000 0x000000 0x000000 RW  0x10

If this program header were not there (or said RWX instead of RW), then 
I expect the kernel would make the stack executable, for backwards 
compatibility.

And the test reports this:

# Subtests with executable mappings or inconsistent results
        exec  MAP_ANONYMOUS with R|W, then mprotect R|X
        exec  MAP_ANONYMOUS with R|X, then mprotect R|W, mprotect R|X
   FAIL exec  malloc (small) (unexpected result)
   FAIL exec  malloc (page size) (unexpected result)
        exec  MAP_ANONYMOUS, with PROT_EXEC, without mprotect
        exec  file with MAP_PRIVATE, with PROT_EXEC, without mprotect, 
without alias
        exec  file with MAP_SHARED, with PROT_EXEC, without mprotect, 
without alias
        exec  shared memory with MAP_PRIVATE, with PROT_EXEC, without 
mprotect, without alias
        exec  shared memory with MAP_SHARED, with PROT_EXEC, without 
mprotect, without alias
        exec  file with MAP_SHARED, with PROT_EXEC, without mprotect, 
with alias
        exec  shared memory with MAP_SHARED, with PROT_EXEC, without 
mprotect, with alias
        exec  MAP_ANONYMOUS, with PROT_EXEC, with mprotect
        exec  file with MAP_PRIVATE, with PROT_EXEC, with mprotect, 
without alias
        exec  file with MAP_SHARED, with PROT_EXEC, with mprotect, 
without alias
        exec  shared memory with MAP_PRIVATE, with PROT_EXEC, with 
mprotect, without alias
        exec  shared memory with MAP_SHARED, with PROT_EXEC, with 
mprotect, without alias
        exec  file with MAP_SHARED, with PROT_EXEC, with mprotect, with 
alias
        exec  shared memory with MAP_SHARED, with PROT_EXEC, with 
mprotect, with alias

(Sorry for the line wrapping, also available at 
<https://paste.fedoraproject.org/367036/>.)

The tests I'm using are these: <https://pagure.io/execmod-tests>  It 
also covers the stack, but it is not listed in the summary because it is 
not executable.

Only the heap is executable.  Everything else is set up as expected by 
the kernel or by glibc.

Florian

  reply	other threads:[~2016-05-16  8:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 13:41 ppc64 sbrk returns executable heap in 32-bit emulation mode Florian Weimer
2016-05-16  6:24 ` Alan Modra
2016-05-16  8:51   ` Florian Weimer [this message]
     [not found] ` <20160516062425.GA24091__32035.8907142237$1463379977$gmane$org@bubble.grove.modra.org>
2016-05-16  8:49   ` Andreas Schwab
2016-05-16  8:59     ` Florian Weimer
2016-05-16  9:09       ` Andreas Schwab
2016-05-16 16:27         ` Florian Weimer

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=998d04cd-6653-7029-51a6-2540ec7dd798@redhat.com \
    --to=fweimer@redhat.com \
    --cc=amodra@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.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;
as well as URLs for NNTP newsgroup(s).