[LTP] [PATCH v2] mprotect04: Support execute-only page access permissions

[Will Deacon]

On Wed, Feb 20, 2019 at 03:59:57PM +0800, Li Wang wrote:
> On Wed, Feb 20, 2019 at 8:21 AM Daniel Mentz <danielmentz@google.com> wrote:
>     No, execute-only page access permissions don't need any special
>     configuration. They have been introduced by the following commit:
> 
>     "arm64: Introduce execute-only page access permissions"
>     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?
>     id=cab15ce604e550020bb7115b779013b91bcdbc21
> 
>     /proc//maps for my mprotect04 executable looks as follows:
> 
>     6458f5e000-6458f62000 r--p 00000000 fd:06 11691                          /
>     data/local/tmp/mprotect04
>     6458f62000-6458f67000 --xp 00004000 fd:06 11691                          /
>     data/local/tmp/mprotect04
>     6458f67000-6458f6a000 rw-p 00009000 fd:06 11691                          /
>     data/local/tmp/mprotect04
>     6458f6a000-6458f6d000 rw-p 00000000 00:00 0 
>     70c5cc0000-70c5d11000 ---p 00000000 00:00 0 
> 
>     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:
> 
> 
> Not sure if that's a issue or intentional in design, Cc'ing Deacon and Catalin
> to have look.

I suspect this depends on the flags that are emitted in the program header
by your compiler. What does objdump -p say for your binary?

Will