linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	linux-fsdevel@vger.kernel.org, brauner@kernel.org,
	 viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
	 linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	gregkh@linuxfoundation.org,  linux-mm@kvack.org,
	liam.howlett@oracle.com, surenb@google.com,  rppt@kernel.org,
	adobriyan@gmail.com
Subject: Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API
Date: Mon, 8 Jul 2024 20:14:48 -0700	[thread overview]
Message-ID: <CAEf4Bzbj7zCUzh2thV-Wkk-YjX71tDLPjb=wc6ZF4HbG5nqPRw@mail.gmail.com> (raw)
In-Reply-To: <ZoySCNydQ-bW6Yg_@tassilo>

On Mon, Jul 8, 2024 at 6:27 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> > So what exactly did you have in mind when you were proposing that
> > check? Did you mean to do a pass over all VMAs within the process to
> > check if there is at least one executable VMA belonging to
> > address_space? If yes, then that would certainly be way too expensive
> > to be usable.
>
> I was thinking to only report the build ID when the VMA queried
> is executable. If software wanted to look up a data symbol
> and needs that buildid it would need to check a x vma too.

I think that's way too restrictive and for no good reason, tbh. If
there is some .rodata ELF section mapped as r/o VMA, I don't see any
reason why user shouldn't be able to request build ID for it.

>
> Normally tools iterate over all the mappings anyways so this
> shouldn't be a big burden for them.
>

This API aims to make this unnecessary. So that tools can request only
relevant VMAs based on whatever captured data or code addresses it got
from, say, profiling of perf events. And if there are some locks or
other global data structures that fall into mapped portions of ELF
data sections, the ability to get build ID for those is just as
important as getting build ID for executable sections.

> Did I miss something?
>
> I guess an alternative would be a new VMA flag, but iirc we're low on
> bits there already.

I think we should just keep things as is. I don't think there is any
real added security in restricting this just to executable VMAs.

>
> -Andi

  reply	other threads:[~2024-07-09  3:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 17:08 [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 1/6] fs/procfs: extract logic for getting VMA name constituents Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 2/6] fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API Andrii Nakryiko
2024-06-27 23:00   ` Andi Kleen
2024-06-28 16:36     ` Andrii Nakryiko
2024-06-28 22:33       ` Andi Kleen
2024-06-28 23:03         ` Andrii Nakryiko
2024-07-02 14:49           ` Andi Kleen
2024-07-02 23:08             ` Andrii Nakryiko
2024-07-08 23:43             ` Andrii Nakryiko
2024-07-09  1:27               ` Andi Kleen
2024-07-09  3:14                 ` Andrii Nakryiko [this message]
2024-07-29 15:47   ` Jann Horn
2024-07-29 16:52     ` Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 4/6] docs/procfs: call out ioctl()-based PROCMAP_QUERY command existence Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 5/6] tools: sync uapi/linux/fs.h header into tools subdir Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 6/6] selftests/proc: add PROCMAP_QUERY ioctl tests Andrii Nakryiko
2024-06-27 19:59 ` [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps Andrew Morton
2024-06-27 20:50   ` Andrii Nakryiko
2024-06-27 21:11     ` Andrew Morton
2024-06-28 16:42       ` Andrii Nakryiko
2024-07-10 18:32 ` Andrew Morton
2024-07-10 18:41   ` Andrii Nakryiko
2024-07-11 18:07 ` Liam R. Howlett
2024-07-24 16:32   ` Alexey Dobriyan

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='CAEf4Bzbj7zCUzh2thV-Wkk-YjX71tDLPjb=wc6ZF4HbG5nqPRw@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=liam.howlett@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).