Handling of USR2 signal in JVM on Linux

[David Lloyd]

On Fri, Jun 17, 2022 at 1:05 AM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>
>>
>> > >
>> > > 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).

`siginfo_t` is POSIX so I wouldn't worry much about it being anything
other than the sender's process ID in the year 2022. Testing that
`Thread::current=NULL` tells you that the thread that the signal was
delivered to doesn't have a Java thread, I guess, but it doesn't tell
you if the signal was invalid in the case where the target thread does
have a corresponding Java thread; after all, a process signal sent
from outside could be sent to any thread as you say. Checking the
sending PID tells you with certainty whether or not the signal did
come from outside, which is really the salient question AFAICT.

-- 
- DML • he/him