Re: ppc64 sbrk returns executable heap in 32-bit emulation mode

Alan Modra [off-list ref] writes:

On Thu, May 12, 2016 at 03:41:09PM +0200, Florian Weimer wrote:

quoted

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.

The stack and the heap are separate mappings.

 (If
I'm wrong about heap+stack needing the same protection then I can't
think of any reason to require an executable heap.)

The heap and the BSS initially share the same page.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On 05/16/2016 10:49 AM, Andreas Schwab wrote:

quoted

 (If
I'm wrong about heap+stack needing the same protection then I can't
think of any reason to require an executable heap.)

The heap and the BSS initially share the same page.

But my test says that at least part of .bss in the main executable is 
*not* executable.

Any ideas why the kernel behaves the way it does?  Can we change the 
behavior at least for ELF binaries which use glibc (or something else 
which indicates a non-legacy binary)?

Thanks,
Florian

Florian Weimer [off-list ref] writes:

But my test says that at least part of .bss in the main executable is
*not* executable.

Build with -mbss-plt -Wl,--bss-plt.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On 05/16/2016 11:09 AM, Andreas Schwab wrote:

Florian Weimer [off-list ref] writes:

quoted

But my test says that at least part of .bss in the main executable is
*not* executable.

Build with -mbss-plt -Wl,--bss-plt.

This gives me:

   FAIL exec  .bss data (unexpected result)
   FAIL exec  .data (unexpected result)
   FAIL exec  malloc (small) (unexpected result)
   FAIL exec  malloc (page size) (unexpected result)

And this is somewhat expected: There is an RWX LOAD segment which covers 
.bss and .data, and it also overlaps with the heap.

So maybe we can change the kernel heap default in case there is no RWX 
LOAD segment, so that most binaries get a non-executable heap?  What do 
you think?

Thanks,
Florian