In windows and linux x86 (including x86_64) world, is there any legitimate binary (i.e., a program binary generated by the typical compiling-assembling-linking flow and no manual editing on binary after it is generated) that will have RWX memory pages after being loaded? If yes, what are the use cases?
Note: this answer corresponds to the original question
Process segment permissions may vary across architectures and implementations. For example, it is expected that on more recent x86 Linux systems that GCC creates binaries with non-executable stacks. In contrast with this, it used to be the case that MIPS did not even support an non-executable stack - in other words, every MIPS binary had its stack permissions set to RWE.
MIPS floating point support requires that any instruction that cannot be directly executed by the FPU, be emulated by the kernel. Part of this emulation involves executing non-FPU instructions that fall in the delay slots of FP branch instructions. Since the beginning of MIPS/Linux time, this has been done by placing the instructions on the userspace thread stack, and executing them there, as the instructions must be executed in the MM context of the thread receiving the emulation.
Because of this, the de facto MIPS Linux userspace ABI requires that the userspace thread have an executable stack. It is de facto, because it is not written anywhere that this must be the case, but it is never the less a requirement.
A kernel patch had to be developed in order to support MIPS executable stack protection:
The following series implements an executable stack protection in MIPS.
It sets up a per-thread 'VDSO' page and appropriate TLB support. Page is set write-protected from user and is maintained via kernel VA. MIPS FPU emulation is shifted to new page and stack is relieved for execute protection as is as all data pages in default setup during ELF binary initialization. The real protection is controlled by GLIBC and it can do stack protected now as it is done in other architectures and I learned today that GLIBC team is ready for this.
Note: actual execute-protection depends from HW capability, of course.
This patch is required for MIPS32/64 R2 emulation on MIPS R6 architecture.
Here is a concrete example, using a MIPS ELF binary from a ZTE router:
$ file cspd
cspd: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
Note the permissions of segment
$ readelf -l cspd
Elf file type is EXEC (Executable file)
Entry point 0x59d790
There are 8 program headers, starting at offset 52
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00400034 0x00400034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x00400134 0x00400134 0x00014 0x00014 R 0x1
[Requesting program interpreter: /lib/ld-uClibc.so.0]
REGINFO 0x000148 0x00400148 0x00400148 0x00018 0x00018 R 0x4
LOAD 0x000000 0x00400000 0x00400000 0x1ef050 0x1ef050 R E 0x10000
LOAD 0x1ef050 0x005ff050 0x005ff050 0x148e2 0x2a070 RW 0x10000
DYNAMIC 0x000160 0x00400160 0x00400160 0x00130 0x00130 RWE 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 <---
NULL 0x000000 0x00000000 0x00000000 0x00000 0x00000 0x4
Section to Segment mapping:
03 .interp .reginfo .dynamic .hash .dynsym .dynstr .init .text .MIPS.stubs .fini .rodata
04 .data.rel.ro .data .rld_map .got .sbss .bss
1. Patchwork MIPS: Allow FPU emulator to use non-stack area.
It seems some .NET native binaries, e.g.
System.ni.dll have an RWX
.xdata section, although I believe they're not generated by a normal compilation workflow (they're produced by
ngen AFAIK) so they're probably not covered by the current version of the question.