Handling of USR2 signal in JVM on Linux

[Thomas Stüfe]

>
>
> > >
> > > I see your point. I dislike crashes, especially ones they can be
> > > reliably triggered from outside. You never can be sure about the
> > > security implications either.
> > >
> > > If you dislike ignoring the signal, and since the default action for
> > > SIGUSR1+2 is process termination, why not exit the VM with an error
> > > message instead? At least we don’t have what looks like a random
> > > segfault, and we could print out the sender pid  too.
> >
> > We could ... but then do we do that for every other signal that can be
> > thrown at the JVM from externally and which will leads to crashes? Where
> > do you stop?
>
>
It's a very limited set. I'd say we limit this to

1) signal for which we registered handlers: the handlers should at least
not crash or vanish the VM without a trace
2) signals which may conceivably be sent to the VM in the normal course of
events: if the default action is to terminate the VM, we should handle them

Note that for (2), we already do this for some signals. We explicitly
handle SIGPIPE (https://bugs.openjdk.org/browse/JDK-4229104) and SIGXFSZ (
https://bugs.openjdk.org/browse/JDK-6499219) because they kill the VM.


> Well, playing devil's advocate, why not? Would it be more complex than
> adding a
>
>     if (si.si_pid != my_cached_pid) {
>         // it came from Outside, let's exit with 128+signum
>         // ...
>     }
>
> to the top of the signal handler(s)?
>
> --
> - DML • he/him
>
>
I filed a JBS issue and a PR:
https://github.com/openjdk/jdk/pull/9181#issuecomment-1157353776.

I went with a different approach, just using Thread::current=NULL as an
indicator. I was worried that Unix implementations may leave the si_pid
field empty, or that it gets filled with the sender's kernel thread id, not
the process pid. Just verified that on Linux, its really actually the
process id (so the main threads id).

Cheers, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220617/9b9be065/attachment-0001.htm>