5 ms·

Fedora 31 has decided to allow (and have) giant process IDs (PIDs)

29 points by LinuxBender 7y ago

ggm 7y ago
I think the author is correct that the primary likely problem is mapping pid values into DB or textual files, with fixed fieldwidth assumptions. What this made me realize, is that because I do this so little overtly, I hadn't even considered it a high risk. I do have pids in files: /var/run/nginx.pid style. They aren't fixed width fields. Top and the like may mis-display on a wide pid I guess, unless its set to use some truncating field but then you get a problem of mis-attributing the PID value to the truncated value, cut/paste.. BOOM
im3w1l 7y ago
The Real WTF is "to make pid collisions less likely", presumably to paper over a race condition triggered when a pid gets reallocated too quickly.
- gdhgxhs 7y ago
  No, it's because it isn't unreasonable to have more than 32,768 processes on a sufficiently large host.
  - im3w1l 7y ago
    I quoted from the code comment.
- londons_explore 7y ago
  If you have a 64 bit PID, and guarantee they will never be reused, you have just eliminated a whole slew of race conditions and security vulnerabilities, and can probably eliminate a lot of other code designed to avoid said things.
  - zaarn 7y ago
    I would go for a 128bit PID; a 64bit PID runs danger of collision if 2^32 processes have been created and killed. A 128bit PID is unlikely to ever collide and you can write code with the assumption that a PID is uniquely identifying to a process and will not be reused or collide in any reasonable timeframe (100 years or so).
    - im3w1l 7y ago
      The pids are allocated sequentially rather than randomly, so birthday paradox isn't an issue here.
      - zaarn 7y ago
        If going for big PIDs I'd do random assignment, means people will stop doign any kind of assumption about PIDs and stops potential side-channel leakage.
        londons_explore 7y ago
        You can still do random assignment but never allocate the same ID twice. There are a bunch of methods to do that quickly and securely - for example use the result of encrypting a counter with a key only the kernel knows. There are benefits to sequential allocation - for one thing, the PID doesn't need to be stored anywhere (which can matter on very low memory machines), and optimizations can be made when there are only a handful of PID's.
        perl4ever 7y ago
        "There are a bunch of methods to do that quickly and securely - for example use the result of encrypting a counter with a key only the kernel knows." That isn't a guarantee, technically though, is it? And if you consider it guaranteed, then why wouldn't a (P)RNG be just as trustworthy? Is there a mathematical argument why it's better?
- jraph 7y ago
  It immediately made me think about CRIU - Checkpoint / Restore in Userspace [1], which needs to be able to restore a process with the same PID as when the checkpoint is taken. When restoring, if a process already has this PID, restoring fails. [1] https://criu.org/ https://criu.org/
  - touisteur 7y ago
    More and more I wonder if the future of criu isn't all namespaces...
    - jraph 7y ago
      They do advise using namespaces, and one of their main use cases is indeed docker container migration.
      - touisteur 7y ago
        Thanks for the info. Do you know where to find recent news and follow the progress of the criu project?
        jraph 7y ago
        Sorry, I just noticed your comment. Upvoting you, hoping that you will notice mine. Unfortunately I don't know anything specific, I haven't followed CRIU. I noticed they did a number of releases during the last years, since I needed to compile CRIU for work. I would take a look at their website [1], it seems to list recent events and they have a mailing list. [1] https://criu.org/Main_Page https://criu.org/Main_Page
- zaarn 7y ago
  There is quite a few fun bugs you can have. HTOP can race when it reads the process PID and then tries to kill it. If in the meantime, that process dies and a new process gets it's PID, then HTOP will kill the wrong process. There is procfd's nowadays that let you have a consistent handle on a specific process, but it doesn't solve the problem for anything that looks at PIDs. It also naturally limits you to hosting only 32K processes; my browser at work consumes almost 1000 PIDs mainly via a lot of threads running at the same time. At home where I have even more tabs open, it's likely that it is getting close to 5000 threads running. Of those 32K processes, only 27k remain, which is a significant chunk. I believe PID is a bit of a dated way to refer to processes and ultimately we should move to opaque process handles (like procfd).
  - im3w1l 7y ago
    Do all syscalls that take a pid have a procfd equivalent?
    - zbentley 7y ago
      No.
  - JdeBP 7y ago
    Like the procdesc system on FreeBSD, which has some rather unfortunate semantics though. (Closing last open descriptors kills processes, by default.) One could make a collection of bugs that are revealed by (quite normal) process ID re-use. One of particular note in this context is the bug that occurs when one is using Linux control groups in lieu of proper job objects (which Linux does not have) and trying to do what on an actual first-class job object would be a "terminate all processes in this job" system call. * http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html * https://github.com/systemd/systemd/issues/6803 https://github.com/systemd/systemd/issues/6803
fargle 7y ago
Love the comments. Lennart (likely Lennart Poettering) explains why it was done, to be anonymously snarked by someone who clearly doesn't like it or him. at all. Lovely and so helpful. I don't know if I'm a systemd fan (yeah, I'm not), but there's nothing wrong with having more than 32K PIDs. At all. If your software breaks, it's stupid and broken and needs to be fixed.
- mathw 7y ago
  I've never understood the level of vitriol directed at systemd and Lennart. I can understand having technical disagreements, but the hate has been astonishing. And it's still going on.
- tinus_hn 7y ago
  Not a problem if Fedora decides this. But it is a problem if systemd decides this. Lennart needs to learn he doesn’t get to push his preferences on everyone, which this is. No it doesn’t cause problems. Yes it’s a preference, keep your hands off of it.
  - jraph 7y ago
    Well, if this does not cause problems and it improves some things, it is probably a better default, no? Distributions using systemd may still change the default if they wish.
    - tinus_hn 7y ago
      No, it’s a preference. Don’t make excuses. Note that this is exactly the reason why anything Lennart does is met with vitriol. He can’t keep his hands out of the cookie jar and when challenged, he and his supporters bring on the excuses. It is not for Lennart or his supporters to decide what’s better for me. That’s for the distributors to decide. Systemd does not get to decide preferences and neither does it get to set defaults.
      - fargle 7y ago
gnu8 7y ago
22 bits sounds completely reasonable to me. From the word giant I was afraid they were going to be 64 bits.
- blaser-waffle 7y ago
  I was thinking Jumbo Frames. "1500 bytes of payload"
- perl4ever 7y ago
  Everything should have an identifier that can't collide with anything including objects of different types. I think typical GUIDs are 128-bits, so best go with that. https://xkcd.com/865/ https://xkcd.com/865/
LinuxBender 7y ago
FWIW, Linux has supported large PID's for a very long time. It just hasn't been default until now. I only mention because of the wording "decided to allow". It's been allowed for a very long time.

29 points by LinuxBender 7y ago

ggm 7y ago

I think the author is correct that the primary likely problem is mapping pid values into DB or textual files, with fixed fieldwidth assumptions. What this made me realize, is that because I do this so little overtly, I hadn't even considered it a high risk. I do have pids in files: /var/run/nginx.pid style. They aren't fixed width fields. Top and the like may mis-display on a wide pid I guess, unless its set to use some truncating field but then you get a problem of mis-attributing the PID value to the truncated value, cut/paste.. BOOM

im3w1l 7y ago

The Real WTF is "to make pid collisions less likely", presumably to paper over a race condition triggered when a pid gets reallocated too quickly.

gdhgxhs 7y ago
No, it's because it isn't unreasonable to have more than 32,768 processes on a sufficiently large host.
- im3w1l 7y ago
  I quoted from the code comment.
londons_explore 7y ago
If you have a 64 bit PID, and guarantee they will never be reused, you have just eliminated a whole slew of race conditions and security vulnerabilities, and can probably eliminate a lot of other code designed to avoid said things.
- zaarn 7y ago
  I would go for a 128bit PID; a 64bit PID runs danger of collision if 2^32 processes have been created and killed. A 128bit PID is unlikely to ever collide and you can write code with the assumption that a PID is uniquely identifying to a process and will not be reused or collide in any reasonable timeframe (100 years or so).
  - im3w1l 7y ago
    The pids are allocated sequentially rather than randomly, so birthday paradox isn't an issue here.
    - zaarn 7y ago
      If going for big PIDs I'd do random assignment, means people will stop doign any kind of assumption about PIDs and stops potential side-channel leakage.
      - londons_explore 7y ago
        You can still do random assignment but never allocate the same ID twice. There are a bunch of methods to do that quickly and securely - for example use the result of encrypting a counter with a key only the kernel knows. There are benefits to sequential allocation - for one thing, the PID doesn't need to be stored anywhere (which can matter on very low memory machines), and optimizations can be made when there are only a handful of PID's.
        perl4ever 7y ago
        "There are a bunch of methods to do that quickly and securely - for example use the result of encrypting a counter with a key only the kernel knows." That isn't a guarantee, technically though, is it? And if you consider it guaranteed, then why wouldn't a (P)RNG be just as trustworthy? Is there a mathematical argument why it's better?
jraph 7y ago
It immediately made me think about CRIU - Checkpoint / Restore in Userspace [1], which needs to be able to restore a process with the same PID as when the checkpoint is taken. When restoring, if a process already has this PID, restoring fails. [1] https://criu.org/ https://criu.org/
- touisteur 7y ago
  More and more I wonder if the future of criu isn't all namespaces...
  - jraph 7y ago
    They do advise using namespaces, and one of their main use cases is indeed docker container migration.
    - touisteur 7y ago
      Thanks for the info. Do you know where to find recent news and follow the progress of the criu project?
      - jraph 7y ago
        Sorry, I just noticed your comment. Upvoting you, hoping that you will notice mine. Unfortunately I don't know anything specific, I haven't followed CRIU. I noticed they did a number of releases during the last years, since I needed to compile CRIU for work. I would take a look at their website [1], it seems to list recent events and they have a mailing list. [1] https://criu.org/Main_Page https://criu.org/Main_Page
zaarn 7y ago
There is quite a few fun bugs you can have. HTOP can race when it reads the process PID and then tries to kill it. If in the meantime, that process dies and a new process gets it's PID, then HTOP will kill the wrong process. There is procfd's nowadays that let you have a consistent handle on a specific process, but it doesn't solve the problem for anything that looks at PIDs. It also naturally limits you to hosting only 32K processes; my browser at work consumes almost 1000 PIDs mainly via a lot of threads running at the same time. At home where I have even more tabs open, it's likely that it is getting close to 5000 threads running. Of those 32K processes, only 27k remain, which is a significant chunk. I believe PID is a bit of a dated way to refer to processes and ultimately we should move to opaque process handles (like procfd).
- im3w1l 7y ago
  Do all syscalls that take a pid have a procfd equivalent?
  - zbentley 7y ago
    No.
- JdeBP 7y ago
  Like the procdesc system on FreeBSD, which has some rather unfortunate semantics though. (Closing last open descriptors kills processes, by default.) One could make a collection of bugs that are revealed by (quite normal) process ID re-use. One of particular note in this context is the bug that occurs when one is using Linux control groups in lieu of proper job objects (which Linux does not have) and trying to do what on an actual first-class job object would be a "terminate all processes in this job" system call. * http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html * https://github.com/systemd/systemd/issues/6803 https://github.com/systemd/systemd/issues/6803

fargle 7y ago

Love the comments. Lennart (likely Lennart Poettering) explains why it was done, to be anonymously snarked by someone who clearly doesn't like it or him. at all. Lovely and so helpful. I don't know if I'm a systemd fan (yeah, I'm not), but there's nothing wrong with having more than 32K PIDs. At all. If your software breaks, it's stupid and broken and needs to be fixed.

mathw 7y ago
I've never understood the level of vitriol directed at systemd and Lennart. I can understand having technical disagreements, but the hate has been astonishing. And it's still going on.
tinus_hn 7y ago
Not a problem if Fedora decides this. But it is a problem if systemd decides this. Lennart needs to learn he doesn’t get to push his preferences on everyone, which this is. No it doesn’t cause problems. Yes it’s a preference, keep your hands off of it.
- jraph 7y ago
  Well, if this does not cause problems and it improves some things, it is probably a better default, no? Distributions using systemd may still change the default if they wish.
  - tinus_hn 7y ago
    No, it’s a preference. Don’t make excuses. Note that this is exactly the reason why anything Lennart does is met with vitriol. He can’t keep his hands out of the cookie jar and when challenged, he and his supporters bring on the excuses. It is not for Lennart or his supporters to decide what’s better for me. That’s for the distributors to decide. Systemd does not get to decide preferences and neither does it get to set defaults.
    - fargle 7y ago

gnu8 7y ago

22 bits sounds completely reasonable to me. From the word giant I was afraid they were going to be 64 bits.

blaser-waffle 7y ago
I was thinking Jumbo Frames. "1500 bytes of payload"
perl4ever 7y ago
Everything should have an identifier that can't collide with anything including objects of different types. I think typical GUIDs are 128-bits, so best go with that. https://xkcd.com/865/ https://xkcd.com/865/

LinuxBender 7y ago

FWIW, Linux has supported large PID's for a very long time. It just hasn't been default until now. I only mention because of the wording "decided to allow". It's been allowed for a very long time.