<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 21, 2019 at 7:01 AM Will Deacon <<a href="mailto:will.deacon@arm.com">will.deacon@arm.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 20, 2019 at 03:59:57PM +0800, Li Wang wrote:<br>
> On Wed, Feb 20, 2019 at 8:21 AM Daniel Mentz <<a href="mailto:danielmentz@google.com" target="_blank">danielmentz@google.com</a>> wrote:<br>
> No, execute-only page access permissions don't need any special<br>
> configuration. They have been introduced by the following commit:<br>
> <br>
> "arm64: Introduce execute-only page access permissions"<br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/</a>?<br>
> id=cab15ce604e550020bb7115b779013b91bcdbc21<br>
> <br>
> /proc//maps for my mprotect04 executable looks as follows:<br>
> <br>
> 6458f5e000-6458f62000 r--p 00000000 fd:06 11691 /<br>
> data/local/tmp/mprotect04<br>
> 6458f62000-6458f67000 --xp 00004000 fd:06 11691 /<br>
> data/local/tmp/mprotect04<br>
> 6458f67000-6458f6a000 rw-p 00009000 fd:06 11691 /<br>
> data/local/tmp/mprotect04<br>
> 6458f6a000-6458f6d000 rw-p 00000000 00:00 0 <br>
> 70c5cc0000-70c5d11000 ---p 00000000 00:00 0 <br>
> <br>
> The notable difference are the access permissions of the second VMA which<br>
> are "--xp". In your case, the permissions were "r-xp", hence reading was<br>
> allowed in addition to execution. I should also note that most other<br>
> binaries on my device like /system/bin/sh don't have the execute-only<br>
> mapping "--xp". Instead, they only have an "r-xp" VMA like your mprotect04.<br>
> In the end, I couldn't find out why there's a difference. Objdump and<br>
> readelf both show that the respective segment is execute-only, but it's<br>
> somehow still mapped readable and executable:<br>
> <br>
> <br>
> Not sure if that's a issue or intentional in design, Cc'ing Deacon and Catalin<br>
> to have look.<br>
<br>
I suspect this depends on the flags that are emitted in the program header<br>
by your compiler. What does objdump -p say for your binary?<br>
<br></blockquote><div><br></div><div>Not sure if this question was meant for Li or me.</div><div>On my system, the objdump output looks as follows:</div><div><br></div><div><div>$ objdump -p out/target/product/crosshatch/system/bin/sh</div><div><br></div><div>out/target/product/crosshatch/system/bin/sh: file format elf64-littleaarch64</div><div><br></div><div>Program Header:</div><div> PHDR off 0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3</div><div> filesz 0x0000000000000230 memsz 0x0000000000000230 flags r--</div><div> INTERP off 0x0000000000000270 vaddr 0x0000000000000270 paddr 0x0000000000000270 align 2**0</div><div> filesz 0x0000000000000015 memsz 0x0000000000000015 flags r--</div><div> LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12</div><div> filesz 0x0000000000009f94 memsz 0x0000000000009f94 flags r--</div><div> LOAD off 0x000000000000a000 vaddr 0x000000000000a000 paddr 0x000000000000a000 align 2**12</div><div> filesz 0x000000000003a450 memsz 0x000000000003a450 flags --x</div><div> LOAD off 0x0000000000045000 vaddr 0x0000000000045000 paddr 0x0000000000045000 align 2**12</div><div> filesz 0x00000000000025f0 memsz 0x0000000000004cc8 flags rw-</div><div> DYNAMIC off 0x0000000000046e80 vaddr 0x0000000000046e80 paddr 0x0000000000046e80 align 2**3</div><div> filesz 0x0000000000000200 memsz 0x0000000000000200 flags rw-</div><div> RELRO off 0x0000000000046000 vaddr 0x0000000000046000 paddr 0x0000000000046000 align 2**0</div><div> filesz 0x00000000000015f0 memsz 0x0000000000002000 flags r--</div><div>EH_FRAME off 0x0000000000005498 vaddr 0x0000000000005498 paddr 0x0000000000005498 align 2**2</div><div> filesz 0x0000000000000d64 memsz 0x0000000000000d64 flags r--</div><div> STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0</div><div> filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-</div><div> NOTE off 0x0000000000000288 vaddr 0x0000000000000288 paddr 0x0000000000000288 align 2**2</div><div> filesz 0x0000000000000038 memsz 0x0000000000000038 flags r--</div><div><br></div></div><div>The second "LOAD" segment is defined with "flags --x". After looking at the kernel source file fs/binfmt_elf.c, my understanding is that this should translate into a VMA that is mapped execute-only. However, when looking at /proc//maps, the corresponding VMA is mapped "read and execute". I couldn't find out why there's a discrepancy. A different binary i.e. mprotect04 looked similar in "objdump -p", but its code segment got indeed mapped execute-only. I currently don't have the objdump output for that binary, but I can get it if needed. To conclude, I noticed that ELF segments marked as "--x" are sometimes mapped execute-only and sometimes read-and-execute.</div><div>We are using an Android kernel based on Linux 4.9.153</div></div></div></div></div></div></div></div>