linux-kernel - Re: [GIT PULL] vfs pidfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 12 Mar 2024 21:09:26 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs pidfd

On Tue, Mar 12, 2024 at 09:23:55AM -0700, Linus Torvalds wrote:
> On Tue, 12 Mar 2024 at 07:16, Christian Brauner <brauner@...nel.org> wrote:
> >
> > No, the size of struct pid was the main reason but I don't think it
> > matters. A side-effect was that we could easily enforce 64bit inode
> > numbers. But realistically it's trivial enough to workaround. Here's a
> > patch for what I think is pretty simple appended. Does that work?
> 
> This looks eminently sane to me. Not that I actually _tested_it, but
> since my testing would have compared it to my current setup (64-bit
> and CONFIG_FS_PID=y) any testing would have been pointless because
> that case didn't change.
> 
> Looking at the patch, I do wonder how much we even care about 64-bit
> inodes. I'd like to point out how 'path_from_stashed()' only takes a
> 'unsigned long ino' anyway, and I don't think anything really cares
> about either the high bits *or* the uniqueness of that inode number..
> 
> And similarly, i_ino isn't actually *used* for anything but naming to
> user space.

It's used to compare pidfs and someone actually already sent a pull
request for this to another project iirc. So it'd be good to keep that
property.

But if your point is that we don't care about this for 32bit then I do
agree. We could do away with the checks completely and just accept the
truncation for 32bit. If that's your point feel free to just remove the
32bit handling in the patch and apply it. Let me know. Maybe I
misunderstood.

> 
> So I'm not at all sure the whole 64-bit checks are worth it. Am I
> missing something else?