4 ms·

> This means that Firefox can't spin up a new content process if the update has replaced the executable with a different version. Couldn't it spin up another o

> This means that Firefox can't spin up a new content process if the update has replaced the executable with a different version. Couldn't it spin up another one from the old version by doing execve("/proc/self/exe", ...)? Or by keeping a template process around with all the libraries loaded from which a child process can then be forked.

dblohm7 5y ago
Completely possible, but that's not how it works ATM. EDIT: And at the risk of stating the obvious, the fact that it doesn't work this way should be a hint that there are complexities involved that make it more complicated than "just" doing it.
- phendrenad2 5y ago
  I don't agree. The fact that it doesn't work is not necessarily a hint that there are complexities involved. There are a myriad of other possible reasons, such as no one really cares that Firefox forces you to restart the app whenever it updates. People just get used to it.
  - kaba0 5y ago
    Or you know, most apps dislike having the executable file itself replaced under them and getting into an unknowably bad state, for basically null benefits. Distros should handle multiple versions of the same program, a la nix, and programs should not optimize for random things like that.
    - phendrenad2 5y ago
      That's just a defeatist attitude. Why does the executable need to be replaced? Why can't the new executable be called firefoxNext, and when firefox starts next time, it checks for this file, and if it exists, it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that? EDIT: Oh, I see. This happens when the distro package manager updates firefox. I don't have a solution, since there isn't an easy one that will satisfy all people. So nevermind. shrug Maybe Firefox could create a temporary executable copy of itself and run from there, and run that, so when the original is replaced, it doesn't affect the running process. But, that probably comes with a host of complications that I'm unaware of.
      - viraptor 5y ago
        > it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that? You'd have to enable all users to replace files owned by root somehow - which is a bad idea. Alternatively you'd have to somehow extend the packaging to support owning either/or file and being able to verify the installed files that way - which would be a massive change.
  - dblohm7 5y ago
    I've been privy to the discussions at Mozilla about this topic. I can assure you, things are not the way they are out of either laziness or ignorance.
kevincox 5y ago
I don't know about the `/proc/self/exe` but I think it would work if they use the same binary (I think they do). I don't know how many other config files or libraries may also be read, but maybe those have better comparability. As for the template process one major issue is that this means that you only get ASLR once on browser start, instead of for every content process, which somewhat reduces the benefits.
rockdoe 5y ago
Couldn't it spin up another one from the old version by doing execve("/proc/self/exe", ...)? 99% of the Firefox code is in libxul.so, so you'd need to get the file handles from the original process or something similar.
- account42 5y ago
  They could have one pristine unused content process and then just fork new ones from that.
kelnos 5y ago
On my system, /proc/self/exe is just a symlink to wherever the program is on disk, not a copy or a reference to the image in memory.
- makomk 5y ago
  If I remember rightly, some of the things in /proc that look like symlinks don't actually behave like them - opening them opens the actual file that the process has open, even if it's been deleted and a new file created at the same location.

dblohm7 5y ago

Completely possible, but that's not how it works ATM. EDIT: And at the risk of stating the obvious, the fact that it doesn't work this way should be a hint that there are complexities involved that make it more complicated than "just" doing it.

phendrenad2 5y ago
I don't agree. The fact that it doesn't work is not necessarily a hint that there are complexities involved. There are a myriad of other possible reasons, such as no one really cares that Firefox forces you to restart the app whenever it updates. People just get used to it.
- kaba0 5y ago
  Or you know, most apps dislike having the executable file itself replaced under them and getting into an unknowably bad state, for basically null benefits. Distros should handle multiple versions of the same program, a la nix, and programs should not optimize for random things like that.
  - phendrenad2 5y ago
    That's just a defeatist attitude. Why does the executable need to be replaced? Why can't the new executable be called firefoxNext, and when firefox starts next time, it checks for this file, and if it exists, it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that? EDIT: Oh, I see. This happens when the distro package manager updates firefox. I don't have a solution, since there isn't an easy one that will satisfy all people. So nevermind. shrug Maybe Firefox could create a temporary executable copy of itself and run from there, and run that, so when the original is replaced, it doesn't affect the running process. But, that probably comes with a host of complications that I'm unaware of.
    - viraptor 5y ago
      > it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that? You'd have to enable all users to replace files owned by root somehow - which is a bad idea. Alternatively you'd have to somehow extend the packaging to support owning either/or file and being able to verify the installed files that way - which would be a massive change.
- dblohm7 5y ago
  I've been privy to the discussions at Mozilla about this topic. I can assure you, things are not the way they are out of either laziness or ignorance.

kevincox 5y ago

I don't know about the `/proc/self/exe` but I think it would work if they use the same binary (I think they do). I don't know how many other config files or libraries may also be read, but maybe those have better comparability. As for the template process one major issue is that this means that you only get ASLR once on browser start, instead of for every content process, which somewhat reduces the benefits.

rockdoe 5y ago

Couldn't it spin up another one from the old version by doing execve("/proc/self/exe", ...)? 99% of the Firefox code is in libxul.so, so you'd need to get the file handles from the original process or something similar.

account42 5y ago
They could have one pristine unused content process and then just fork new ones from that.

kelnos 5y ago

On my system, /proc/self/exe is just a symlink to wherever the program is on disk, not a copy or a reference to the image in memory.

makomk 5y ago
If I remember rightly, some of the things in /proc that look like symlinks don't actually behave like them - opening them opens the actual file that the process has open, even if it's been deleted and a new file created at the same location.