[RFC PATCH] fdinfo: Option for public fdinfo

[RFC PATCH] fdinfo: Option for public fdinfo

[David Francis]

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.

Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
for that file available to read for processes without ptrace
permissions.

Note that this makes public how many files each process has open,
and what their fds are.

Signed-off-by: David Francis <David.Francis@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 fs/proc/fd.c                            | 24 ++++++++++++++++++++++--
 include/linux/fs.h                      |  2 ++
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 03814a23eb54..89eabeee5836 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_PUBLIC_FDINFO,
 };
 
 int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 9eeccff49b2a..e48854f6a28d 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -86,13 +86,34 @@ static int proc_fdinfo_permission(struct mnt_idmap *idmap, struct inode *inode,
 				  int mask)
 {
 	bool allowed = false;
+	struct file *file = NULL;
+	struct files_struct *files = NULL;
 	struct task_struct *task = get_proc_task(inode);
 
 	if (!task)
 		return -ESRCH;
 
-	allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
+	task_lock(task);
+	files = task->files;
+	if (files) {
+		unsigned int fd = proc_fd(inode);
+
+		spin_lock(&files->file_lock);
+		file = files_lookup_fd_locked(files, fd);
+		if (file)
+			get_file(file);
+		spin_unlock(&files->file_lock);
+	}
+	task_unlock(task);
+
+	if (file)
+		allowed = file->f_op->fop_flags & FOP_PUBLIC_FDINFO;
+
+	if (!allowed)
+		allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
+
 	put_task_struct(task);
+	fput(file);
 
 	if (!allowed)
 		return -EACCES;
@@ -401,7 +422,6 @@ static int proc_fdinfo_iterate(struct file *file, struct dir_context *ctx)
 
 const struct inode_operations proc_fdinfo_inode_operations = {
 	.lookup		= proc_lookupfdinfo,
-	.permission	= proc_fdinfo_permission,
 	.setattr	= proc_setattr,
 };
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dd3b57cfadee..0444086868d5 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 without ptrace access */
+#define FOP_PUBLIC_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

Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian Brauner]

On Mon, Mar 16, 2026 at 02:38:28PM -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.
> 
> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
> for that file available to read for processes without ptrace
> permissions.
> 
> Note that this makes public how many files each process has open,
> and what their fds are.
> 
> Signed-off-by: David Francis <David.Francis@amd.com>
> ---

Eew, please let's not. Add an ioctl if you need to be able to retrieve
that info.

Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian König]

On 3/23/26 13:13, Christian Brauner wrote:
> On Mon, Mar 16, 2026 at 02:38:28PM -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.
>>
>> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
>> for that file available to read for processes without ptrace
>> permissions.
>>
>> Note that this makes public how many files each process has open,
>> and what their fds are.
>>
>> Signed-off-by: David Francis <David.Francis@amd.com>
>> ---
> 
> Eew, please let's not. Add an ioctl if you need to be able to retrieve
> that info.

Yeah the problem is an IOCTL is even worse from the security pov.

This is for an tool which doesn't have access to the file descriptor which provides that information.

So using pidfd_getfd() or similar to get the FD and then call an IOCTL on it would be a security violation.

The real question is how should we make this information public available in the system?

Regards,
Christian.

Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian Brauner]

On Mon, Mar 23, 2026 at 02:16:59PM +0100, Christian König wrote:
> On 3/23/26 13:13, Christian Brauner wrote:
> > On Mon, Mar 16, 2026 at 02:38:28PM -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.
> >>
> >> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
> >> for that file available to read for processes without ptrace
> >> permissions.
> >>
> >> Note that this makes public how many files each process has open,
> >> and what their fds are.
> >>
> >> Signed-off-by: David Francis <David.Francis@amd.com>
> >> ---
> > 
> > Eew, please let's not. Add an ioctl if you need to be able to retrieve
> > that info.
> 
> Yeah the problem is an IOCTL is even worse from the security pov.
> 
> This is for an tool which doesn't have access to the file descriptor which provides that information.
> 
> So using pidfd_getfd() or similar to get the FD and then call an IOCTL on it would be a security violation.
> 
> The real question is how should we make this information public available in the system?

Don't you have a way to make this info available in sysfs? Just like
networking exposes info about network devices in there that may come and
go?

Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian König]

On 3/24/26 09:53, Christian Brauner wrote:
> On Mon, Mar 23, 2026 at 02:16:59PM +0100, Christian König wrote:
>> On 3/23/26 13:13, Christian Brauner wrote:
>>> On Mon, Mar 16, 2026 at 02:38:28PM -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.
>>>>
>>>> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
>>>> for that file available to read for processes without ptrace
>>>> permissions.
>>>>
>>>> Note that this makes public how many files each process has open,
>>>> and what their fds are.
>>>>
>>>> Signed-off-by: David Francis <David.Francis@amd.com>
>>>> ---
>>>
>>> Eew, please let's not. Add an ioctl if you need to be able to retrieve
>>> that info.
>>
>> Yeah the problem is an IOCTL is even worse from the security pov.
>>
>> This is for an tool which doesn't have access to the file descriptor which provides that information.
>>
>> So using pidfd_getfd() or similar to get the FD and then call an IOCTL on it would be a security violation.
>>
>> The real question is how should we make this information public available in the system?
> 
> Don't you have a way to make this info available in sysfs? Just like
> networking exposes info about network devices in there that may come and
> go?

Yeah that was already tried as well and Greg summarized it as "sometimes you don't know how horrible something is until you tried it".

So the memory accounting parts for DMA-buf files in sysfs were deprecated and removed again just a few weeks ago. And that was basically just a subset of what David tries to do here.

The requirement is that you want to be able to access the stats for accelerators/GPUs drivers similar to how tools like "top" or "htop" work. E.g. everybody can access /proc/*/stat as well, it's just that some security related information are left out.

As far as I can see we have only a couple of different options to fulfill that requirement and lowering the security for fdinfo like David's patch here suggests still looks like the most defensive one to me.

Regards,
Christian.

Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian Brauner]

On Tue, Mar 24, 2026 at 10:30:26AM +0100, Christian König wrote:
> On 3/24/26 09:53, Christian Brauner wrote:
> > On Mon, Mar 23, 2026 at 02:16:59PM +0100, Christian König wrote:
> >> On 3/23/26 13:13, Christian Brauner wrote:
> >>> On Mon, Mar 16, 2026 at 02:38:28PM -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.
> >>>>
> >>>> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
> >>>> for that file available to read for processes without ptrace
> >>>> permissions.
> >>>>
> >>>> Note that this makes public how many files each process has open,
> >>>> and what their fds are.
> >>>>
> >>>> Signed-off-by: David Francis <David.Francis@amd.com>
> >>>> ---
> >>>
> >>> Eew, please let's not. Add an ioctl if you need to be able to retrieve
> >>> that info.
> >>
> >> Yeah the problem is an IOCTL is even worse from the security pov.
> >>
> >> This is for an tool which doesn't have access to the file descriptor which provides that information.
> >>
> >> So using pidfd_getfd() or similar to get the FD and then call an IOCTL on it would be a security violation.
> >>
> >> The real question is how should we make this information public available in the system?
> > 
> > Don't you have a way to make this info available in sysfs? Just like
> > networking exposes info about network devices in there that may come and
> > go?
> 
> Yeah that was already tried as well and Greg summarized it as "sometimes you don't know how horrible something is until you tried it".
> 
> So the memory accounting parts for DMA-buf files in sysfs were deprecated and removed again just a few weeks ago. And that was basically just a subset of what David tries to do here.
> 
> The requirement is that you want to be able to access the stats for accelerators/GPUs drivers similar to how tools like "top" or "htop" work. E.g. everybody can access /proc/*/stat as well, it's just that some security related information are left out.
> 
> As far as I can see we have only a couple of different options to fulfill that requirement and lowering the security for fdinfo like David's patch here suggests still looks like the most defensive one to me.

It's not acceptable to make /proc/<pid>/fdinfo accessible just to carve
out an exception for you. You can look at implementing something like
taskstats based on netlink transpart if you want to.