From: Christian Brauner <brauner@kernel.org>
To: David Francis <David.Francis@amd.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Alexander.Deucher@amd.com, Christian.Koenig@amd.com,
Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Subject: Re: [PATCH] fdinfo: Add fops flag to allow CAP_PERFMON to see fdinfo
Date: Tue, 12 May 2026 14:29:05 +0200 [thread overview]
Message-ID: <20260512-einlegen-ehedrama-26b2c2bb8918@brauner> (raw)
In-Reply-To: <20260504191429.1770840-1-David.Francis@amd.com>
On Mon, May 04, 2026 at 03:14:29PM -0400, David Francis wrote:
> We want some GPU information to be publicly available to all
> processes for basic system-wide profiling (think GPU versions
> of top).
>
> This information is available in fdinfo and not easily exposed
> by other interfaces.
>
> Allow processes with CAP_PERFMON capability to
> - read /proc/<pid>/fd
> - follow symlinks in /proc/<pid>/fd, but only if that file has
> new file operations flag FOP_PERFMON_FDINFO
> - read /proc/<pid>/fdinfo
> - read /proc/<pid>/fdinfo/<fd>, but only if that file has
> FOP_PERFMON_FDINFO
>
> Signed-off-by: David Francis <David.Francis@amd.com>
> Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> fs/proc/base.c | 18 ++++++++++++++++
> fs/proc/fd.c | 28 ++++++++++++++++++++++++-
> include/linux/fs.h | 2 ++
> 4 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 03814a23eb54..d62f8b400258 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -3022,7 +3022,7 @@ static const struct file_operations amdgpu_driver_kms_fops = {
> #ifdef CONFIG_PROC_FS
> .show_fdinfo = drm_show_fdinfo,
> #endif
> - .fop_flags = FOP_UNSIGNED_OFFSET,
> + .fop_flags = FOP_UNSIGNED_OFFSET | FOP_PERFMON_FDINFO,
> };
>
> int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv)
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 6299878e3d97..83182ff6b96d 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -86,6 +86,7 @@
> #include <linux/user_namespace.h>
> #include <linux/fs_parser.h>
> #include <linux/fs_struct.h>
> +#include <linux/fdtable.h>
> #include <linux/slab.h>
> #include <linux/sched/autogroup.h>
> #include <linux/sched/mm.h>
> @@ -716,6 +717,23 @@ static bool proc_fd_access_allowed(struct inode *inode)
> task = get_proc_task(inode);
> if (task) {
> allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
> + if (!allowed && capable(CAP_PERFMON)) {
> + struct files_struct *files;
> +
> + task_lock(task);
> + files = task->files;
> + if (files) {
> + struct file *file;
> +
> + spin_lock(&files->file_lock);
> + file = files_lookup_fd_locked(files,
> + proc_fd(inode));
> + allowed = file && file->f_op->fop_flags &
> + FOP_PERFMON_FDINFO;
> + spin_unlock(&files->file_lock);
> + }
> + task_unlock(task);
> + }
No, sorry, that's such a blatant layering violation tying together
capabilities restricted to a specific file operation marked via an FOP
flag. That is such a bad precedent to set. Let's not go there.
Also, if you don't have ptrace access rights to a process but then hold
a global capability as an additional escape hatch is such a twisted
security model.
You're trying to shoehorn gpu specific introspection into a generic
interface that has absolutely no business exempting them. Build your own
dedicated interface please and don't try forcing this into procfs in
this way, please.
Procfs has a very peculiar security model for very good reasons and
ptrace_may_access() is the canonical check - with enough special sauce
as it is. Let's not add opaque escape hatches for magic file
descriptors and open us up for more security suprises...
> put_task_struct(task);
> }
> return allowed;
> diff --git a/fs/proc/fd.c b/fs/proc/fd.c
> index 9eeccff49b2a..89c1a205148a 100644
> --- a/fs/proc/fd.c
> +++ b/fs/proc/fd.c
> @@ -86,12 +86,35 @@ static int proc_fdinfo_permission(struct mnt_idmap *idmap, struct inode *inode,
> int mask)
> {
> bool allowed = false;
> - struct task_struct *task = get_proc_task(inode);
> + struct task_struct *task;
>
> + task = get_proc_task(inode);
> if (!task)
> return -ESRCH;
>
> allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
> +
> + if (!allowed && capable(CAP_PERFMON)) {
> + struct files_struct *files;
> +
> + if (S_ISDIR(inode->i_mode)) {
> + allowed = true;
> + } else {
> + task_lock(task);
> + files = task->files;
> + if (files) {
> + struct file *file;
> +
> + spin_lock(&files->file_lock);
> + file = files_lookup_fd_locked(files, proc_fd(inode));
> + allowed = file && file->f_op->fop_flags &
> + FOP_PERFMON_FDINFO;
> + spin_unlock(&files->file_lock);
> + }
> + task_unlock(task);
> + }
> + }
> +
> put_task_struct(task);
>
> if (!allowed)
> @@ -338,6 +361,9 @@ int proc_fd_permission(struct mnt_idmap *idmap,
> if (rv == 0)
> return rv;
>
> + if (capable(CAP_PERFMON))
> + return 0;
> +
> rcu_read_lock();
> p = pid_task(proc_pid(inode), PIDTYPE_PID);
> if (p && same_thread_group(p, current))
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index dd3b57cfadee..bc2826e1cc38 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2327,6 +2327,8 @@ struct file_operations {
> #define FOP_ASYNC_LOCK ((__force fop_flags_t)(1 << 6))
> /* File system supports uncached read/write buffered IO */
> #define FOP_DONTCACHE ((__force fop_flags_t)(1 << 7))
> +/* fdinfo readable with CAP_SYS_PERFMON */
> +#define FOP_PERFMON_FDINFO ((__force fop_flags_t)(1 << 8))
>
> /* Wrap a directory iterator that needs exclusive inode access */
> int wrap_directory_iterator(struct file *, struct dir_context *,
> --
> 2.34.1
>
prev parent reply other threads:[~2026-05-12 12:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 19:14 [PATCH] fdinfo: Add fops flag to allow CAP_PERFMON to see fdinfo David Francis
2026-05-12 12:29 ` Christian Brauner [this message]
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=20260512-einlegen-ehedrama-26b2c2bb8918@brauner \
--to=brauner@kernel.org \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=David.Francis@amd.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tvrtko.ursulin@igalia.com \
/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