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
next prev parent 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).