Unrecoverable stack overflow due to missing guard pages

Vitaly Davidovich vitalyd at gmail.com
Sat Sep 27 19:08:09 UTC 2014


Hi Dmitry,

Thanks for replying.  I agree with your points - simply wanted to double
check my understanding of the issue and the patch.  This has nasty
consequences for the JVM, unfortunately, but yeah, I don't see any
foolproof way to fix it at the VM layer.

Thanks

Sent from my phone
On Sep 27, 2014 3:07 AM, "Dmitry Samersoff" <dmitry.samersoff at oracle.com>
wrote:

> Vitaly,
>
> 1. If one of dependent DSO has executable stack this patch will not work
> and hotspot would have a problem.
>
> 2. I don't see any good way to handle it on hotspot side.
>
> 3. Personally, I think that this situation have to be addressed on
> OS/DSO vendor side, because executable stack is a huge security whole.
>
> -Dmitry
>
> On 2014-09-27 02:22, Vitaly Davidovich wrote:
> > Hi all,
> >
> > Noticed this bug report:
> https://bugs.openjdk.java.net/browse/JDK-7107135
> >
> > However, it appears that even with 7u60 this same problem occurs.  Is
> that
> > fix supposed to work if a dependent native lib (.so on linux) has an
> > executable stack flag set? The case I'm seeing is just like that: a JNI
> > call is made to a native library whose ELF stack is not executable, but a
> > dependent lib does have that flag set.
> >
> > The fix associated with the above bug report appears to detect such a lib
> > being loaded but only directly (I.e. via System.loadLibrary).  Is that
> > correct? Also, is there anything planned to attempt to handle this for
> > indirectly loaded libs?
> >
> > Thanks
> >
> > Sent from my phone
> >
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
>


More information about the hotspot-runtime-dev mailing list