public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] mprotect04: Support execute-only page access permissions
Date: Thu, 21 Feb 2019 15:01:37 +0000	[thread overview]
Message-ID: <20190221150137.GA13320@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <CAEemH2dx8q9u2bSwrGE3Li72shOMtsQQECRT_MftOdUqcOPQzA@mail.gmail.com>

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

  reply	other threads:[~2019-02-21 15:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12  0:00 [LTP] [PATCH v2] mprotect04: Support execute-only page access permissions Daniel Mentz
2019-02-19 13:34 ` Li Wang
2019-02-20  0:21   ` Daniel Mentz
2019-02-20  7:59     ` Li Wang
2019-02-21 15:01       ` Will Deacon [this message]
2019-02-21 20:43         ` Daniel Mentz
2019-02-22  3:13           ` Li Wang
2019-02-22 11:16             ` Will Deacon
2019-02-25  7:39 ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190221150137.GA13320@fuggles.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox