<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Li,</div><div><br></div><div>No, execute-only page access permissions don't need any special configuration. They have been introduced by the following commit:</div><div><br></div><div>"arm64: Introduce execute-only page access permissions"<br></div><div dir="ltr"><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cab15ce604e550020bb7115b779013b91bcdbc21" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cab15ce604e550020bb7115b779013b91bcdbc21</a><br></div><div dir="ltr"><br></div><div dir="ltr"><div>/proc//maps for my mprotect04 executable looks as follows:</div><div dir="ltr"><br></div><div dir="ltr">6458f5e000-6458f62000 r--p 00000000 fd:06 11691 /data/local/tmp/mprotect04</div><div dir="ltr">6458f62000-6458f67000 --xp 00004000 fd:06 11691 /data/local/tmp/mprotect04</div><div dir="ltr">6458f67000-6458f6a000 rw-p 00009000 fd:06 11691 /data/local/tmp/mprotect04</div><div dir="ltr">6458f6a000-6458f6d000 rw-p 00000000 00:00 0 </div><div dir="ltr">70c5cc0000-70c5d11000 ---p 00000000 00:00 0 </div><div dir="ltr"><br></div><div>The notable difference are the access permissions of the second VMA which are "--xp". In your case, the permissions were "r-xp", hence reading was allowed in addition to execution. I should also note that most other binaries on my device like /system/bin/sh don't have the execute-only mapping "--xp". Instead, they only have an "r-xp" VMA like your mprotect04. In the end, I couldn't find out why there's a difference. Objdump and readelf both show that the respective segment is execute-only, but it's somehow still mapped readable and executable:</div><div><br></div><div><div># head /proc/$$/maps</div><div>5cf18f9000-5cf1903000 r--p 00000000 fd:03 3361 /system/bin/sh</div><div>5cf1903000-5cf193e000 r-xp 0000a000 fd:03 3361 /system/bin/sh</div><div>5cf193e000-5cf193f000 rw-p 00045000 fd:03 3361 /system/bin/sh</div><div>5cf193f000-5cf1941000 r--p 00046000 fd:03 3361 /system/bin/sh</div></div><div><br></div><div>I should also mention that we compiled mprotect04 with clang instead of gcc. Maybe that makes a difference.</div><div>We are using an Android kernel based on Linux 4.9.153</div><div><br></div><div>Daniel</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 5:34 AM Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Daniel,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 8:00 AM Daniel Mentz <<a href="mailto:danielmentz@google.com" target="_blank">danielmentz@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Linux version 4.9 introduced support for execute-only page access permissions on<br>
arm64. As a result, user space processes, by default, cannot read from<br>
their own .text sections. This change adds an extra call to mprotect()<br>
to explicitly change access protections to allow relevant parts of the<br>
.text section to be read.<br>
<br>
Without this change, mprotect04 generates false TBROK results. We<br>
previously saw this test output:<br>
<br>
mprotect04 1 TPASS : test PROT_NONE for mprotect success<br>
mprotect04 0 TINFO : exec_func: 0x5ac82d3588, page_to_copy: 0x5ac82d3000<br>
mprotect04 2 TBROK : ltp/testcases/kernel/syscalls/mprotect/mprotect04.c:236: page_to_copy not present<br>
mprotect04 3 TBROK : ltp/testcases/kernel/syscalls/mprotect/mprotect04.c:236: Remaining cases broken<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I believe your patch make sense, but I can't reproduce that problem on my aarch64 platform with upstream kernel-v5.0-rc7. Is that execute-only page permission needs a special config to enable? or can you point me which commit made the change?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">===== without your patch ====</div><div class="gmail_default" style="font-size:small"><div># uname -rm</div><div>5.0.0-rc7 aarch64</div><div><br></div></div><div class="gmail_default"><div class="gmail_default" style="font-size:small"># ./mprotect04 </div><div class="gmail_default" style="font-size:small">mprotect04 1 TPASS : test PROT_NONE for mprotect success</div><div class="gmail_default" style="font-size:small">mprotect04 2 TPASS : test PROT_EXEC for mprotect success</div><div style="font-size:small"><br></div><div>I confirmed the '&exec_func == 0x403460' has READ&EXEC permission in the .text section. Or, did I missed anything?<br></div><div><br></div></div><div class="gmail_default">00400000-00420000 r-xp 00000000 fd:00 101414360 /root/ltp/testcases/kernel/syscalls/mprotect/mprotect04</div><div class="gmail_default">00420000-00430000 r--p 00010000 fd:00 101414360 /root/ltp/testcases/kernel/syscalls/mprotect/mprotect04</div><div class="gmail_default">00430000-00440000 rw-p 00020000 fd:00 101414360 /root/ltp/testcases/kernel/syscalls/mprotect/mprotect04</div><div class="gmail_default">2ff00000-2ff30000 rw-p 00000000 00:00 0 [heap]</div><div class="gmail_default">ffff86b00000-ffff86b20000 --xp 00000000 00:00 0 </div><div class="gmail_default">ffff86b20000-ffff86c80000 r-xp 00000000 fd:00 1164 /usr/lib64/<a href="http://libc-2.28.so" target="_blank">libc-2.28.so</a></div><div class="gmail_default">ffff86c80000-ffff86c90000 r--p 00150000 fd:00 1164 /usr/lib64/<a href="http://libc-2.28.so" target="_blank">libc-2.28.so</a></div><div class="gmail_default">ffff86c90000-ffff86ca0000 rw-p 00160000 fd:00 1164 /usr/lib64/<a href="http://libc-2.28.so" target="_blank">libc-2.28.so</a></div><div class="gmail_default">ffff86cb0000-ffff86cc0000 r--p 00000000 00:00 0 [vvar]</div><div class="gmail_default">ffff86cc0000-ffff86cd0000 r-xp 00000000 00:00 0 [vdso]</div><div class="gmail_default">ffff86cd0000-ffff86cf0000 r-xp 00000000 fd:00 1157 /usr/lib64/<a href="http://ld-2.28.so" target="_blank">ld-2.28.so</a></div><div class="gmail_default">ffff86cf0000-ffff86d00000 r--p 00010000 fd:00 1157 /usr/lib64/<a href="http://ld-2.28.so" target="_blank">ld-2.28.so</a></div><div class="gmail_default">ffff86d00000-ffff86d10000 rw-p 00020000 fd:00 1157 /usr/lib64/<a href="http://ld-2.28.so" target="_blank">ld-2.28.so</a></div><div class="gmail_default">ffffed310000-ffffed340000 rw-p 00000000 00:00 0 [stack]</div><div class="gmail_default" style="font-size:small"></div></div></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_1224468564012438872gmail-m_309954429267104227gmail-m_-347759937322634449m_-7423080029794906821gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div></div></div></div></div>
</blockquote></div>