signal chaining and self defence

Wed May 19 18:54:44 UTC 2010

Hello Everyone,

(sorry for the delay, but something went wrong with my subscription, i 
haven't noticed that I already got an answer)

comments inline...

> More info from Hotspot engineers.
>
> ----
>   >Does webstart allow running your own native code in an applet?
yes

>   (Does
> plugin while
>   >So I am guessing that they have java interfaces using the jvm/JIT
>   >     - then gluegen   -- how does gluegen work here? Is it precompiled
>    
gluegen generates very thin JNI binding code, its precompiled -> nothing 
at runtime.

but we have basically two modes: static linking against libOpenCL.so or 
dynamic loading and invocation via function pointers which we currently 
use for JOGL but not yet for JOCL (except for CL extensions).

> or does it do a translation at run time?
>    
no

>   >     - which talks to OpenCL "C" binaries
>   >     - there appear to be a set running on the "host" or main CPU,
>   >        including interfacing to the underlying device drivers, such as
> the amd and nvidia drivers mentioned
>   >      - which then can also start OpenCL "C" binaries that run on
> auxiliary processors like GPUs
>    
yes thats basically how it works

>   >So to answer Michael's question from a VM perspective:
>
>   >It appears that the amd and nvidia native drivers that I would guess
> they link to in their
>   >"host" code register for the system signals listed below, but don't
> support signal chaining,
>   >i.e. they are overwriting the jvm's signal handlers.
>
>   >So - the technical solution for that, assuming we can't change the amd
> and nvidia drivers,
>   >is to interpose our libjsig.so before their libraries are loaded. This
> lets our vm chain
>   >their signal handlers, so that the VM only handles signals that apply
> to the vm and then
>   >calls their signal handlers.
>
>   >I am guessing they can't link libjsig with their application or he
> would have done so - but
>   >it is worth first asking why he can't.
>    
Reading the libjsig doc i thought it would not work.
my understanding of libjsig:
it must be loaded before the most of the JVM starts, thats why there are 
two options:
1.) LD_PRELOAD=path/to/libjsig
2.) link a custom native JVM launcher against libjsig

since webstart does not allow 2.) it won't help.

(please correct me if i am wrong here, otherwise the issue is already 
solved :) )

>   >If it is the case that he can not, then he needs to setenv LD_PRELOAD
> <libjvm.so-directory>/libjsig.so
>   >before starting up java.
>
>   >Is there a way to do that with WebStart? Is there a way to specify to
> do that?
> No - there is no ability to set any env variables before launching
> java.  If jnlp file itself is signed and trusted, you could set system
> propertys before launching java, but not environmental variables.
>    

exactly thats the issue... dead end regarding webstart.

In the meantime i talked to the Nvidia devs and they will try to 
workaround this issue. Looking at the AMD drivers the situation is not 
different but for some reasons it appears to run more stable (but this 
is probably just luck). So we would have to talk to them too and maybe 
other vendors.

Is there a reason why signal chaining is not enabled by default on 
linux/solaris?
If there is a reason, could the webstart launcher enable it only for 
webstart on those systems?

Third way to solve this issue is to introduce a 
"-XX:enableSignalChaining" flag as mentioned before and allow it to be 
passed via JNLP.
This might work since i heard webstart runs out of process anyway... so 
there must be a launcher involved which interprets this flags before JVM 
launch.

to quote my original mail:
It looks like a good self-defence mechanism for me :)

thanks for the support,

best regards,

Michael Bien

> -----
>
> Paul
> >/  A partial answer: one of the Hotspot engineers says
> />/
> />/  "I think the short answer is that chaining requires LD_PRELOAD to
> />/  override the signal entry points. Otherwise we [Hotspot] wouldn't see
> />/  the calls that change the signal handlers. If the Java command itself
> />/  linked against jsig that would work too I think. I believe that's the
> />/  only way to solve the problem he is seeing in an automatic fashion.
> />/  Depending on how the driver library gets loaded they might be able to
> />/  build their own signal handler trampolines to work around it and
> />/  correct the signal handlers after it gets loaded."
> />/
> />/  Regards,
> />/
> />/  Paul
> />/
> />/  On 5/8/10 7:31 AM, Michael Bien wrote:
> />>/  Hello everyone,
> />>/
> />>/  i am one of the maintainers of JOGL and wrote JOCL
> />>/  (http://jogamp.org/) and we are currently facing some signal handling
> />>/  issues caused by the nvidia and amd drivers.
> />>/  (I got the hint to post to this list since there is no better alias
> />>/  for this kind of topics)
> />>/
> />>/  e.g. the nvidia OpenCL driver uses at least the following handlers:
> />>/  Warning: SIGSEGV handler expected:libjvm.so+0x5d8cf0
> />>/  found:libnvidia-compiler.so+0x1865e0
> />>/  Warning: SIGILL handler expected:libjvm.so+0x5d8cf0
> />>/  found:libnvidia-compiler.so+0x1865e0
> />>/  Warning: SIGFPE handler expected:libjvm.so+0x5d8cf0
> />>/  found:libnvidia-compiler.so+0x1865e0
> />>/  Warning: SIGBUS handler expected:libjvm.so+0x5d8cf0
> />>/  found:libnvidia-compiler.so+0x1865e0
> />>/  Warning: SIGXFSZ handler expected:libjvm.so+0x5d8cf0
> />>/  found:libnvidia-compiler.so+0x1865e0
> />>/  (-Xcheck:jni)
> />>/
> />>/  which basically makes the jvm unusable on Linux and leads to
> />>/  segmentation faults (in the driver, I suppose the driver catches jvm
> />>/  signals).
> />>/
> />>/  LD_PRELOAD
> />>/  (http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html#gbzbl)
> />>/  works perfectly but it is not allowed for webstart + applets...
> />>/
> />>/  do you have any advice how we could workaround this issue? The
> />>/  perfect solution would be a "-XX:enableSignalChaining" flag which we
> />>/  could set via jnlp. Since the webstart JVM is out of process anyway
> />>/  (since u10 or so) this would probably work.
> />>/
> />>/  Why isn't signal chaining enabled by default on linux and solaris? It
> />>/  looks like a good self-defence mechanism for me :)
> />>/
> />>/  best regards,
> />>/  Michael Bien
> />>/
> />>/  ---
> />>/
> />>/  http://michael-bien.com
> /-------------- next part --------------
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100519/b95df32a/attachment.html>