[LTP] [PATCH v2] mprotect04: Support execute-only page access permissions
Li Wang
liwang@redhat.com
Tue Feb 19 14:34:03 CET 2019
Hi Daniel,
On Tue, Feb 12, 2019 at 8:00 AM Daniel Mentz <danielmentz@google.com> wrote:
> Linux version 4.9 introduced support for execute-only page access
> permissions on
> arm64. As a result, user space processes, by default, cannot read from
> their own .text sections. This change adds an extra call to mprotect()
> to explicitly change access protections to allow relevant parts of the
> .text section to be read.
>
> Without this change, mprotect04 generates false TBROK results. We
> previously saw this test output:
>
> mprotect04 1 TPASS : test PROT_NONE for mprotect success
> mprotect04 0 TINFO : exec_func: 0x5ac82d3588, page_to_copy:
> 0x5ac82d3000
> mprotect04 2 TBROK :
> ltp/testcases/kernel/syscalls/mprotect/mprotect04.c:236: page_to_copy not
> present
> mprotect04 3 TBROK :
> ltp/testcases/kernel/syscalls/mprotect/mprotect04.c:236: Remaining cases
> broken
>
>
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?
===== without your patch ====
# uname -rm
5.0.0-rc7 aarch64
# ./mprotect04
mprotect04 1 TPASS : test PROT_NONE for mprotect success
mprotect04 2 TPASS : test PROT_EXEC for mprotect success
I confirmed the '&exec_func == 0x403460' has READ&EXEC permission in the
.text section. Or, did I missed anything?
00400000-00420000 r-xp 00000000 fd:00 101414360
/root/ltp/testcases/kernel/syscalls/mprotect/mprotect04
00420000-00430000 r--p 00010000 fd:00 101414360
/root/ltp/testcases/kernel/syscalls/mprotect/mprotect04
00430000-00440000 rw-p 00020000 fd:00 101414360
/root/ltp/testcases/kernel/syscalls/mprotect/mprotect04
2ff00000-2ff30000 rw-p 00000000 00:00 0
[heap]
ffff86b00000-ffff86b20000 --xp 00000000 00:00 0
ffff86b20000-ffff86c80000 r-xp 00000000 fd:00 1164
/usr/lib64/libc-2.28.so
ffff86c80000-ffff86c90000 r--p 00150000 fd:00 1164
/usr/lib64/libc-2.28.so
ffff86c90000-ffff86ca0000 rw-p 00160000 fd:00 1164
/usr/lib64/libc-2.28.so
ffff86cb0000-ffff86cc0000 r--p 00000000 00:00 0
[vvar]
ffff86cc0000-ffff86cd0000 r-xp 00000000 00:00 0
[vdso]
ffff86cd0000-ffff86cf0000 r-xp 00000000 fd:00 1157
/usr/lib64/ld-2.28.so
ffff86cf0000-ffff86d00000 r--p 00010000 fd:00 1157
/usr/lib64/ld-2.28.so
ffff86d00000-ffff86d10000 rw-p 00020000 fd:00 1157
/usr/lib64/ld-2.28.so
ffffed310000-ffffed340000 rw-p 00000000 00:00 0
[stack]
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190219/44ca0d04/attachment.html>
More information about the ltp
mailing list