[11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

[Thomas Stüfe]

On Tue, Mar 19, 2019 at 10:39 AM Andrew Haley <aph at redhat.com> wrote:

> On 3/19/19 7:33 AM, Thomas Stüfe wrote:
>
> > The established (since decades) method of forking off on Linux JDKs
> > has been to use vfork(3). Using vfork is risky. There are chances of
> > crashing the parent process. The risk of this happening is very low,
> > but not zero.
>
> Do you have a reference to this? If we're at risk, I'd like to know
> exactly what the risk is.
>

Sure, see here an old mail from me to core libs last year:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html

(Please ignore my proposed fix, turned out David Loyd's posix_spawn
proposal was a way simpler solution.)

very short version:

After child process is spawned via vfork() but before it calls exec() both
parent and child are vulnerable in the following way:

A signal received by the child may damage or kill the parent. True for both
synchronous (error) signals in the child and outside signals sent to the
child.
    - since the child process code is old and stable, error signals are not
likely, with one possible exception: hitting a stack overflow in the child
process (e.g. when calling fork in a low stack situation)
    - asynchronous signals could be sent from the outside. Unlikely to be a
targeted kill, since the parent cannot yet have communicated the child pid
to the outside; but could be a group kill.

Note that the risk depends on the the length of the time span between fork
and exec, which depends on the number of open file descriptors in the
parent.

As I wrote, the risk is low - a freak accident - but not zero and has a
question mark around it since these crashes are hard to attribute to vfork.
Typical symptom is that the parent process just dies without a trace.

---

As to the question: if it is so important why do we not switch the default?

This is the result of a discussion with the core-libs maintainers and a
trade off between the vfork() risk and the risk of adding this patch. Roger
preferred to provide the non-default alternative for 12 and switch the
default to posix_spawn() for 13.

I think long term it definitely will make sense to switch the default to
posix_spawn on 11 and 12 too, maybe after a grace period.

Cheers, Thomas




> > Since analyzing those crashes and attributing them to vfork(3) is
> > very difficult, there may be a number of reported cases not
> > associated with vfork(3) but in fact caused by it.
>
> > The patch adds a second, safer way to fork off childs, using
> > posix_spawn(3). This one has been the default on other platforms for
> > quite some while. The patch does not change the default fork mode -
> > which remains vfork(3). So installations would not be affected
> > unless they explicitely choose to use vfork(3).
> >
> > Having this possibility would allow us to use posix_spawn(3) in
> > situations where we are analysing crashes and want to exclude
> > vfork(3) as a cause. It also would enable us to use posix_spawn(3)
> > as a safe alternative by default if we choose to do so.
> >
> > In addition to that, as David Loyd mentioned, vfork(3) is marked as
> > obsolete and may be vanish at some point in the life span of JDK
> > 11. I admit the chance of this happening is low.
>
> Sure, but as I replied to him, this patch doesn't solve that problem.
>

Fair enough.



>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>