All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	linux-perf-users@vger.kernel.org, selinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] perf test amd ibs: avoid using executable heap
Date: Wed, 1 Jul 2026 08:43:01 +0200	[thread overview]
Message-ID: <20260701064301.GH48970@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260701062321.517351-1-omosnace@redhat.com>

On Wed, Jul 01, 2026 at 08:23:21AM +0200, Ondrej Mosnacek wrote:
> Making [parts of] the heap executable is dangerous and is blocked by
> SELinux on Fedora/RHEL even for an unconfined user. Replace the malloc()
> + mprotect() combo with just mmap(), creating a private anonymous rwx
> mapping, which only requires the more commonly allowed "execmem"

I do not understand. Ultimately malloc() will have to use mmap() to get
the memory too. So how is malloc() + mprotect() considered more
dangerous?

> permission under SELinux (things like JIT or regex compilation need it
> as well). mmap() with MAP_ANONYMOUS will give us a zeroed mapping that
> begins on a page boundary, so the result is equivalent to the original
> code even without a memset() or the page-alignment dance.

I would argue that having RWX is a problem, you really want RW->RO->RX
transitions, so even with mmap() you want to combine with mprotect().

Obviously this doesn't matter for this test case, but any halfway sane
JIT should really avoid keeping RWX mappings around.

> Verified that the test still passes on a machine with an AMD CPU that
> has the "ibs" CPU flag.
> 
> Fixes: 35db59fa8ea2 ("perf test amd ibs: Add sample period unit test")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>

The patch is obviously good, simpler is more better and all that. But
the justification really smells.

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

If and when we get AMD to support IBT, this thing will need more
changes, but alas.

> ---
> 
> v2: fix mmap() failure check (found by sashiko-bot)
> 
>  tools/perf/arch/x86/tests/amd-ibs-period.c | 20 ++++++--------------
>  1 file changed, 6 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/perf/arch/x86/tests/amd-ibs-period.c b/tools/perf/arch/x86/tests/amd-ibs-period.c
> index 6a92b3a23ed7a..32713f8fcd5c8 100644
> --- a/tools/perf/arch/x86/tests/amd-ibs-period.c
> +++ b/tools/perf/arch/x86/tests/amd-ibs-period.c
> @@ -46,7 +46,6 @@ static int dummy_workload_1(unsigned long count)
>  {
>  	int (*func)(void);
>  	int ret = 0;
> -	char *p;
>  	char insn1[] = {
>  		0xb8, 0x01, 0x00, 0x00, 0x00, /* mov 1,%eax */
>  		0xc3, /* ret */
> @@ -59,18 +58,11 @@ static int dummy_workload_1(unsigned long count)
>  		0xcc, /* int 3 */
>  	};
>  
> -	p = calloc(2, page_size);
> -	if (!p) {
> -		printf("malloc() failed. %m");
> -		return 1;
> -	}
> -
> -	func = (void *)((unsigned long)(p + page_size - 1) & ~(page_size - 1));
> -
> -	ret = mprotect(func, page_size, PROT_READ | PROT_WRITE | PROT_EXEC);
> -	if (ret) {
> -		printf("mprotect() failed. %m");
> -		goto out;
> +	func = mmap(NULL, page_size, PROT_READ | PROT_WRITE | PROT_EXEC,
> +		    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +	if (func == MAP_FAILED) {
> +		pr_debug("mmap() failed. %m\n");
> +		return -1;
>  	}
>  
>  	if (count < 100000)
> @@ -93,7 +85,7 @@ static int dummy_workload_1(unsigned long count)
>  	}
>  
>  out:
> -	free(p);
> +	munmap(func, page_size);
>  	return ret;
>  }
>  
> -- 
> 2.54.0
> 

  parent reply	other threads:[~2026-07-01  6:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01  6:23 [PATCH v2] perf test amd ibs: avoid using executable heap Ondrej Mosnacek
2026-07-01  6:33 ` sashiko-bot
2026-07-01  6:43 ` Peter Zijlstra [this message]
2026-07-01 16:59   ` Ravi Bangoria
2026-07-01 18:54     ` Ian Rogers
2026-07-02 10:17     ` Peter Zijlstra
2026-07-02 11:11       ` Ravi Bangoria
2026-07-09 14:35   ` Ondrej Mosnacek
2026-07-02 11:12 ` Ravi Bangoria
2026-07-06 16:58 ` Namhyung Kim

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=20260701064301.GH48970@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=omosnace@redhat.com \
    --cc=ravi.bangoria@amd.com \
    --cc=selinux@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.