Process ids again

Posted Jun 6, 2025 16:51 UTC (Fri) by AClwn (subscriber, #131323)
In reply to: Process ids again by epa
Parent article: Slowing the flow of core-dump-related CVEs

OpenBSD randomizes its PIDs to reduce predictability and to avoid leaking information (i.e. preventing users from subtracting PIDs to determine how many processes had been created in the interim). Randomized PIDs would be incompatible with a no-reuse guarantee because you'd have to store (and search!) a table of previously-used PIDs.

The obvious retort is that Linux doesn't randomize PIDs and it never will, so the only things you lose by extending PIDs to 64 bits are (1) a little bit of space wherever they're stored and (2) an entire class of PID-reuse security vulnerabilities, and that this is a pretty good tradeoff. I have nothing to say to that; I just wanted to mention PID randomization.

Process ids again

Posted Jun 7, 2025 5:45 UTC (Sat) by epa (subscriber, #39769) [Link] (1 responses)

I suppose if you had a big enough space for the ids you could randomize and still have them in monotone order. Just leave random-sized gaps in the sequence. 64 bits might be enough that you could do that and still never run out of ids.

Process ids again

Posted Jun 22, 2025 9:10 UTC (Sun) by l0kod (subscriber, #111864) [Link]

FYI, Landlock IDs follow this approach. One important difference is that we only need a bijection (i.e. Landlock IDs are not used to get a reference but only to identify an existing object). From the commit description, Landlock IDs have these properties:
- They are unique during the lifetime of the running system thanks to
the 64-bit values: at worse, 2^60 - 2*2^32 useful IDs.
- They are always greater than 2^32 and must then be stored in 64-bit
integer types.
- The initial ID (at boot time) is randomly picked between 2^32 and
2^33, which limits collisions in logs across different boots.
- IDs are sequential, which enables users to order them.
- IDs may not be consecutive but increase with a random 2^4 step, which
limits side channels.

For more details, see https://git.kernel.org/torvalds/c/d9d2a68ed44bbae598a81cb...

Unique randomized wide PIDs

Posted Jun 8, 2025 9:20 UTC (Sun) by jreiser (subscriber, #11027) [Link] (6 responses)

> Randomized PIDs would be incompatible with a no-reuse guarantee because you'd have to store (and search!) a table of previously-used PIDs.

Um, no. A Linear Feedback Shift Register (LFSR) that is based on an irreducible polynomial guarantees uniqueness over its entire period, which is near to 2**N. Just initialize it to a random point in its sequence.

Unique randomized wide PIDs

Posted Jun 8, 2025 10:03 UTC (Sun) by dezgeg (subscriber, #92243) [Link] (5 responses)

Would that really help with anything though, given the sequence is still entirely predictable?

Unique randomized wide PIDs

Posted Jun 8, 2025 18:11 UTC (Sun) by bmenrigh (subscriber, #63018) [Link] (4 responses)

Yeah an LFSR wouldn’t be secure. However a customer block cipher (where the block size matches the PID size) eliminates the predictability issue. Just generate a random key at startup.

Unique randomized wide PIDs

Posted Jun 9, 2025 12:00 UTC (Mon) by bluca (subscriber, #118303) [Link] (3 responses)

Although it is mildly amusing watching the rediscovery of UUIDs in this thread (hint: it's what Windows uses), it is unnecessary: with the new kernel the pidfd inode number is guaranteed unique per boot, so we have a solution for this now (there's also the boot uuid, so the combination of boot uuid + pidfd inode id gives a universal unique identifier, if that is needed). PIDs can never be changed, as all existing software will break. No, it's not just a matter of "recompiling", existing binaries need to work too with new kernels, so that's not an option. But we are starting to expose pidfd inodes in more places now, so I guess they'll slowly take over for new functionality.

Unique randomized wide PIDs

Posted Jun 12, 2025 8:48 UTC (Thu) by donald.buczek (subscriber, #112892) [Link] (2 responses)

However, I wonder how userspace can easily determine whether a pidfd inode number comes from a system that guarantees uniqueness.

Unique randomized wide PIDs

Posted Jun 12, 2025 11:15 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

There was a way, I forget the details, but on systems where it's not unique it's a fixed/hardcoded/well-known inode number, because it's an anonymous inode rather than from pidfdfs? Details are fuzzy so I might be getting this wrong

Unique randomized wide PIDs

Posted Jun 14, 2025 9:45 UTC (Sat) by donald.buczek (subscriber, #112892) [Link]

I found that you can use fstatfs() on the file descriptor and see if f_type == PID_FS_MAGIC ( 0x50494446; /* "PIDF" */ ). On an elder system it is ANON_INODE_FS_MAGIC (0x09041934)

Note, that although pidfd_open(2) says opening a "/proc/[PID]" directory would be an alternative way to get a PID file descriptor, this is only half true: You can use such a file descriptor with pidfd_* calls, but it is another type of file descriptor with f_type == PROC_SUPER_MAGIC ( 0x9fa0 ) and you can't use the inode number from that kind of file descriptor as a unique process identifier.

I still wish, processes had UUIDs.

Process ids again

Posted Jun 9, 2025 16:37 UTC (Mon) by dsfch (subscriber, #176007) [Link]

64bit PIDs would be an ABI break, right ? `pid_t` being 32bit is all over glibc & Co. as well as in `<uapi/asm-generic/posix_types.h>` so it's not just a trivial substitute ?